คำถามติดแท็ก architecture

ฉันกำลังสร้างแอปพลิเคชันใน PHP โดยใช้ Zend Framework 1 และ Doctrine2 เป็นเลเยอร์ ORM ทุกอย่างเป็นไปด้วยดี ตอนนี้ฉันสังเกตเห็นว่าทั้ง ZF1 และ Doctrine2 มาพร้อมกับและใช้งานแคชของพวกเขาเอง ฉันได้ประเมินทั้งสองอย่างและในขณะที่แต่ละคนมีข้อดีและข้อเสียของตัวเองทั้งคู่ต่างก็โดดเด่นกว่าคนอื่นสำหรับความต้องการที่เรียบง่ายของฉัน ดูเหมือนว่าไลบรารีทั้งสองนั้นจะถูกเขียนลงบนอินเตอร์เฟสที่เกี่ยวข้องไม่ใช่การประยุกต์ใช้ เหตุผลที่ฉันรู้สึกว่านี่เป็นปัญหาคือในระหว่างการบูตแอปพลิเคชันของฉันฉันต้องกำหนดค่าแคชไดรเวอร์สองตัว - แต่ละอันมีไวยากรณ์ของตัวเอง ไม่ตรงกันถูกสร้างขึ้นอย่างง่ายดายด้วยวิธีนี้และรู้สึกไม่มีประสิทธิภาพในการตั้งค่าสองการเชื่อมต่อกับแบ็กเอนด์แคชเพราะสิ่งนี้ ฉันกำลังพยายามกำหนดว่าอะไรคือวิธีที่ดีที่สุดในการส่งต่อและยินดีรับข้อมูลเชิงลึกที่คุณสามารถเสนอได้ สิ่งที่ฉันคิดตอนนี้มีสี่ตัวเลือก: ไม่ทำอะไรเลยยอมรับว่ามีสองคลาสที่เสนอฟังก์ชันการแคช สร้างคลาส Facade เพื่อติดอินเทอร์เฟซของ Zend เข้ากับการใช้แคชของ Doctrine ตัวเลือก 2 วิธีอื่น ๆ - สร้าง Facade เพื่อแมปอินเทอร์เฟซของ Doctrine บนแบ็กเอนด์ Zend Framework ใช้หลายอินเทอร์เฟซการสืบทอดเพื่อสร้างอินเทอร์เฟซเดียวเพื่อปกครองทั้งหมดและอธิษฐานว่าไม่มีการซ้อนทับกัน (เช่น: หากทั้งคู่มีวิธี "บันทึก" พวกเขาจะต้องยอมรับพารามิเตอร์ในลำดับเดียวกันเนื่องจาก PHP ขาดความหลากหลายที่เหมาะสม) …

9 php  architecture  third-party-libraries  polymorphism 

ฉันจำการเรียนรู้ VB4 และการลากปุ่มไปยังแบบฟอร์มดับเบิลคลิกที่ปุ่มนั้นและพิมพ์รหัสลงในตัวจัดการเหตุการณ์ที่ฉันเพิ่งได้รับพรอย่างน่าอัศจรรย์ มาจาก QBASIC ฉันตื่นเต้นกับ "V" ใน "VB" นักออกแบบภาพเป็นสิ่งที่ดีที่สุดตั้งแต่ขนมปังหั่นบาง ๆ แน่นอนว่าคุณสามารถทำทุกอย่างได้โดยทางโปรแกรม แต่ความมหัศจรรย์ของ "V" นั้นน่าดึงดูดมากจนคุณอดไม่ได้ที่จะลาก แต่ปุ่ม เราได้รับการสนับสนุนให้ใช้เส้นทางนั้น แต่ไม่กี่ปีที่ผ่านมาฉันเริ่มเรียนรู้เกี่ยวกับ C # และ. net framework และรู้สึกทึ่งกับทุกสิ่งที่ฉันคิดว่าฉันรู้ว่าเพิ่งออกไปนอกหน้าต่าง มีเวทมนต์มากมายที่เกิดขึ้นใน VB6 ที่เปิดเผยอย่างสมบูรณ์ใน. net: ใช้ตัวสร้างและInitializeComponentsวิธีการเช่น ในภายหลังคุณจะพบอินสแตนซ์ควบคุมทั้งหมดที่คุณลากจากกล่องเครื่องมือกิจกรรมทั้งหมดที่คุณลงทะเบียนและคุณสมบัติที่คุณตั้งไว้ในตัวออกแบบ และก็ไม่เป็นไร ... ฉันเดา มันเป็นเพียงฉันรู้สึกเหมือนฉันไม่ "เป็นเจ้าของ" สิ่งที่เกิดขึ้นรหัสนี้ที่ฉันสามารถแก้ไขได้ผ่านทางนักออกแบบสร้างความรำคาญให้กับฉัน ทุกครั้งที่คุณคัดลอกปุ่มที่ระบุว่า "ตกลง" จากแบบฟอร์มหนึ่งไปยังอีกแบบหนึ่ง (บางครั้งพร้อมกับพี่ชายของ "ยกเลิก") คุณกำลังทำรหัสซ้ำจริง ๆ และนั่นเป็นบาปใช่ไหม แห้งจะไม่ทำซ้ำตัวเองกล่าวว่าสมเด็จพระสันตะปาปา ศาสนาและโรงเรียนที่มีความคิดนอกเหนือจากความเป็นกลางทุกอย่างเราไม่ควรได้รับแบบฟอร์มจากรูปแบบพื้นฐานแทนและมีปุ่ม "ตกลง" (และเพื่อน ๆ ทุกคน) …

9 architecture  winforms  designer 

ฉันมีปัญหาในการวาดเส้นที่ชัดเจนระหว่าง Presentation และ Application layer ใน Domain Driven Design ไฟล์คอนโทรลเลอร์, มุมมอง, เลย์เอาต์, Javascript และ CSS ควรไปที่ใด มันอยู่ใน Application หรือเลเยอร์การนำเสนอหรือไม่? และถ้าพวกมันรวมกันในเลเยอร์เดียวกันสิ่งที่มีอีกอันหนึ่ง? มันว่างเปล่า

9 architecture  domain-driven-design  layers 

ฉันเพิ่งเริ่มมีความสนใจในการปฏิบัติที่คล่องตัวในการพัฒนาซอฟต์แวร์และฉันได้เห็นบทความจำนวนมากชี้ให้เห็นว่าการปฏิบัติเหล่านี้ช่วยลดต้นทุนโดยรวม ตรรกะเบื้องหลังที่มักจะเป็นเช่นนี้: หากความต้องการของคุณเปลี่ยนแปลงคุณสามารถสะท้อนการเปลี่ยนแปลงนี้ได้ในงานเร่งด่วนถัดไปและสิ่งนี้จะนำไปสู่การลดค่าใช้จ่ายเนื่องจากการออกแบบคุณลักษณะใหม่และการใช้งาน ค่าใช้จ่ายลดลงตามกฎที่มีชื่อเสียงว่าในภายหลังคุณจำเป็นต้องเปลี่ยนแปลงความต้องการของคุณยิ่งมีราคาแพงมากขึ้นก็จะเป็นไปตามข้อกำหนดนั้น แต่โครงการซอฟต์แวร์ระดับกลางถึงใหญ่นั้นซับซ้อน การเปลี่ยนแปลงข้อกำหนดแบบฉับพลันไม่ได้หมายความว่าคุณจะไม่ต้องสัมผัสส่วนอื่น ๆ ของระบบเพื่อตอบสนองความต้องการนั้น ในหลายกรณีสถาปัตยกรรมจะต้องมีการปรับเปลี่ยนอย่างมากซึ่งหมายความว่าคุณจะต้องใช้คุณลักษณะทั้งหมดที่อาศัยสถาปัตยกรรมเก่าอีกครั้ง ดังนั้นจุดโดยรวมของค่าใช้จ่ายลดลงเลยหายไปที่นี่ แน่นอนถ้าความต้องการใหม่เรียกร้องให้มีส่วนที่เป็นอิสระใหม่ของระบบนั่นไม่ใช่ปัญหาสถาปัตยกรรมเก่าเพิ่งเติบโตขึ้นมันไม่จำเป็นต้องคิดใหม่และนำไปใช้ใหม่ และตรงกันข้าม หากคุณกำลังใช้น้ำตกและคุณรู้ทันทีว่ามีข้อกำหนดใหม่ที่จะต้องนำเสนอคุณสามารถไปและเปลี่ยนการออกแบบของคุณ ถ้าต้องการสถาปัตยกรรมที่มีการเปลี่ยนแปลงคุณต้องออกแบบใหม่ ถ้ามันไม่ได้ยุ่งกับมันจริงๆ แต่เพิ่งจะแนะนำส่วนใหม่ของระบบคุณก็ไปทำทุกอย่างได้อย่างไม่มีปัญหา จากที่กล่าวมาดูเหมือนว่าฉันชอบความได้เปรียบเพียงอย่างเดียวของการพัฒนาแบบว่องไวคือคุณลักษณะการทำงานที่สมบูรณ์สร้างขึ้นระหว่าง sprints และสำหรับผู้คนจำนวนมากและ prjects สิ่งนี้ไม่สำคัญ นอกจากนี้ความคล่องตัวดูเหมือนว่าจะส่งผลให้สถาปัตยกรรมซอฟต์แวร์โดยรวมไม่ดีเนื่องจากฟีเจอร์จะได้รับการตบอย่างใดอย่างหนึ่งทีมเปรียวเพียงดูแลว่าคุณสมบัติการทำงานไม่ใช่วิธีการทำงาน ดูเหมือนว่าเมื่อระบบเติบโตอย่างซับซ้อนตามกาลเวลาการพัฒนาแบบว่องไวจะเพิ่มความสับสนวุ่นวายในสถาปัตยกรรมผลิตภัณฑ์โดยรวมดังนั้นในที่สุดก็ส่งผลให้มีค่าใช้จ่ายสูงขึ้นเนื่องจากจะเป็นการยากที่จะแนะนำการเปลี่ยนแปลงมากขึ้น ก่อนที่คุณจะปล่อยอะไร ใครช่วยชี้ให้ฉันดูว่าฉันไปผิดตรงไหนเพราะเห็นได้ชัดว่าผู้คนจำนวนมากใช้ความคล่องตัวในสภาพแวดล้อมการผลิตดังนั้นฉันต้องผิดที่อื่น

9 project-management  architecture  agile 

ฉันกำลังทำงานกับแอปพลิเคชัน Silverlight ฉันแยกมันออกเป็นหลายชุด โดเมน ที่เก็บข้อมูล (ทุกอย่างที่มีอยู่ในฐานข้อมูล Sterling) UI ... นี่คือวิธีที่ฉันเรียนรู้ แต่ฉันสงสัย หากคุณรู้ว่ากำลังจะไม่ถูกนำมาใช้ซ้ำจะต้องแยกพวกเขาออกหรือไม่ หรือคุณสามารถใส่ทุกอย่างไว้ในแอสเซมบลีเดียวและใช้โฟลเดอร์และเนมสเปซเพื่อทำให้เป็นระเบียบหรือไม่? ฉันเคยเห็นโครงการที่มีชุดประกอบมากเกินไป แทนที่จะใช้เนมสเปซที่เหมาะสม ดังนั้น: เมื่อใดที่คุณจะสร้างชุดประกอบใหม่สำหรับชิ้นส่วนใหม่ของรหัส มีทรัพยากรที่ดีในเรื่องนี้หรือไม่? และคุณแบ่งรหัสทางเทคนิค (โดเมน, ข้อมูล, UI ฯลฯ ) และ / หรือการทำงาน (เช่นการบริหารผู้ป่วย, ผู้ป่วย - แพทย์, โรงพยาบาล - โลจิสติกส์, ... - อาจเป็นเพียงสำหรับแอปพลิเคชันระดับองค์กรที่ใหญ่กว่า)?

9 .net  architecture  visual-studio  code-organization 

พื้นหลัง ฐานข้อมูลท้องถิ่นมีแถวที่ไม่ซ้ำกันเกือบ 1.3 พันล้านแถว แต่ละแถวมีความสัมพันธ์ทางอ้อมกับละติจูดและลองจิจูดเฉพาะ (ตำแหน่ง) แต่ละแถวมีการประทับวันที่ ใช้ Case ปัญหาดังต่อไปนี้: ผู้ใช้ตั้งวันที่เริ่มต้น / สิ้นสุดและช่วงของค่า (เช่น 100 ถึง 105) ระบบรวบรวมแถวทั้งหมดที่ตรงกับวันที่กำหนดจัดกลุ่มตามสถานที่ ระบบดำเนินการกำหนดสถานที่ที่ในช่วงวันที่เหล่านั้นมีความเป็นไปได้ทางสถิติของการตกอยู่ในช่วงของค่าที่กำหนด ระบบจะแสดงตำแหน่งที่ตรงกันทั้งหมดให้กับผู้ใช้ นี่เป็นปัญหาของความเร็วและสเกล คำถาม สถาปัตยกรรมโซลูชันที่มีราคาแพงน้อยที่สุดที่คุณสามารถจินตนาการได้ว่าจะอนุญาตให้ระบบดังกล่าวดึงข้อมูลผลลัพธ์สำหรับผู้ใช้ในเวลาไม่เกินห้าวินาทีคืออะไร ระบบปัจจุบัน สภาพแวดล้อมปัจจุบัน: PostgreSQL 8.4 (สามารถปรับรุ่นได้การสลับฐานข้อมูลไม่ใช่ตัวเลือก) R และ PL / R XFS WD VelociRaptor RAM 8 GB (Corsair G.Skill; 1.3 GHz) Quad core GenuineIntel 7 (2.8 GHz) Ubuntu …

9 architecture  database  geospatial 

ฉันคุ้นเคยกับวิธีการประเมินผลสถาปัตยกรรมเช่นเทคนิควิธีสถาปัตยกรรม tradeoff วิเคราะห์ (Atam)และธุรกิจที่มุ่งเน้นมากขึ้นค่าใช้จ่ายผลประโยชน์ของวิธีการวิเคราะห์ (CBAM) อย่างไรก็ตามวิธีการเหล่านี้มีขนาดใหญ่พอสมควร: พวกเขากำหนดช่วงการระดมสมองหลายครั้งการนำเสนอการพัฒนาโฮสต์ของสถานการณ์ที่อธิบายถึงการแลกเปลี่ยน ฯลฯ ในขณะที่มีประโยชน์สำหรับโครงการที่มีขนาดที่แน่นอนพวกเขามีขนาดใหญ่เกินไปสำหรับโครงการภายใน พัฒนาโดยนักพัฒนาไม่กี่คน (หรือน้อยกว่า) แม้ว่าจะมีขนาดเล็ก แต่ก็มีข้อ จำกัด ด้านคุณภาพค่อนข้างสูง (ประสิทธิภาพ, ความสามารถในการปรับขนาด, ความสามารถในการปรับตัว) การปฏิบัติทั่วไปที่ฉันเคยใช้ในอดีตคือการมีนักพัฒนาหนึ่งคน (หรือสถาปนิกหากทีมมีหนึ่งคน) เพื่อสร้างสถาปัตยกรรมทั่วไปสำหรับแอปพลิเคชันแล้วพูดคุยกันบนกระดานไวท์บอร์ดกับส่วนที่เหลือของทีม เครื่องหมายหลอก - UML บางอย่างที่ง่ายต่อการวาดและเข้าใจ โดยทั่วไปจะนำไปสู่ข้อเสนอแนะและการวนซ้ำในสถาปัตยกรรม แต่มันก็มีแนวโน้มที่จะไม่เป็นทางการเกินไปจนทำให้มีการตั้งสมมติฐานทุกชนิดซึ่งอาจกลายเป็นการตัดสินใจที่ผิดพลาดในภายหลัง วิธีการเช่น Atam มักจะบังคับให้ผู้มีส่วนได้เสียทุกคนที่จะคิดอย่างลึกซึ้งเกี่ยวกับสถาปัตยกรรมซึ่งนำไปสู่การอภิปรายจนทุกคนอย่างน้อยเห็นด้วยกับสิ่งที่สถาปัตยกรรมว่าเป็น ใครบ้างมีประสบการณ์กับการทำการประเมินสถาปัตยกรรมเบื้องหน้าบ้างไหม? ถ้าเป็นเช่นนั้นการปฏิบัติที่ดีคืออะไร?

9 architecture  evaluation 

แนวคิด "บัญญัติ" นั้นแพร่หลายในซอฟต์แวร์ รูปแบบเช่นCanonical Model , Canonical Schema , Canonical Data Modelเป็นต้นดูเหมือนจะเกิดขึ้นซ้ำแล้วซ้ำอีกในการพัฒนา เช่นเดียวกับนักพัฒนาหลายคนฉันมักจะติดตามอย่างไม่ถี่ถ้วนภูมิปัญญาดั้งเดิมที่คุณต้องการแบบจำลองที่เป็นที่ยอมรับมิฉะนั้นคุณจะต้องเผชิญกับการระเบิดของนักทำแผนที่และนักแปล หรืออย่างน้อยฉันก็เคยทำเช่นนั้นจนกระทั่งสองสามปีที่ผ่านมาเมื่อฉันอ่านEF Vote of No Confidence เป็นครั้งแรก: สมมติฐานที่ครั้งหนึ่งเคยสนับสนุนการแสวงหารูปแบบข้อมูลที่ยอมรับไม่ได้และไม่สามารถรวมปัจจัยที่จะค้นพบได้เมื่อแนวคิดถูกนำไปใช้จริง เราพบว่าผ่านการลองผิดลองถูกมาหลายปีว่าการใช้แบบจำลองแยกต่างหากสำหรับแต่ละบริบทซึ่งอาจใช้แบบจำลองข้อมูลแคนนอนเป็นวิธีที่ซับซ้อนน้อยที่สุดเป็นวิธีที่มีค่าใช้จ่ายน้อยที่สุดและเป็นวิธีหนึ่งที่นำไปสู่ ของแอพพลิเคชั่นและอุปกรณ์ปลายทางโดยใช้แบบจำลองตามบริบทและเป็นวิธีการที่ไม่สนับสนุนให้เอนโทรปีของซอฟต์แวร์ที่เป็นแบบจำลองมาตรฐานยอมรับ บทความนี้ไม่มีหลักฐานใด ๆ ที่สนับสนุนข้อเรียกร้องของมัน แต่ทำให้ฉันสงสัยว่าวิธีการ CDM นั้นนานพอที่จะลองใช้ทางเลือกอื่นและซอฟต์แวร์ที่ได้นั้นไม่ได้ระเบิดอย่างแท้จริงหรือเป็นรูปเป็นร่าง แต่นั่นไม่ได้แปลว่าโดดเดี่ยวทั้งหมด ฉันเพิ่งจะโชคดี ดังนั้นฉันจึงสงสัยว่ามีการวิจัยอย่างจริงจังในเรื่องของผลกระทบระยะยาวในทางปฏิบัติของการมีแบบจำลองมาตรฐานและแบบจำลองเชิงบริบทในระบบซอฟต์แวร์หรือสถาปัตยกรรมหรือไม่? หรือถ้ามันยังเร็วเกินไปที่จะถามว่ามีนักพัฒนา / สถาปนิกคนใดเขียนเกี่ยวกับประสบการณ์ส่วนตัวที่เปลี่ยนจาก CDM เป็นแบบจำลองตามบริบทอิสระหรือในทางกลับกันและสิ่งที่เกิดขึ้นจริงในเรื่องการผลิตความซับซ้อนหรือความน่าเชื่อถือ แล้วความแตกต่างในระดับต่าง ๆ คือการใช้แบบจำลองเดียวกันในแอพพลิเคชั่นเดียวกับการใช้ข้ามระบบของแอพพลิเคชั่นหรือทั้งองค์กร (โปรดข้อเท็จจริงเท่านั้นยินดีต้อนรับเรื่องราวสงคราม แต่ไม่มีการเก็งกำไร)

9 design-patterns  architecture  data  domain-model 

ทีมงานของเราเดิมประกอบด้วยนักพัฒนาด้านเซิร์ฟเวอร์ส่วนใหญ่ที่มีความเชี่ยวชาญขั้นต่ำใน Javascript ใน ASP.NET เราเคยเขียนตรรกะ UI จำนวนมากในโค้ดหลังหรือมากกว่านั้นเมื่อเร็ว ๆ นี้ผ่านคอนโทรลเลอร์ใน MVC เมื่อไม่นานมานี้นักพัฒนาด้านลูกค้าระดับสูง 2 คนได้เข้าร่วมทีมของเรา พวกเขาสามารถทำได้ใน HTMl / CSS / Javascript ทุกอย่างที่เราสามารถทำได้กับโค้ดฝั่งเซิร์ฟเวอร์และการควบคุมเว็บฝั่งเซิร์ฟเวอร์: แสดง / ซ่อนส่วนควบคุม ทำการตรวจสอบ ควบคุมการรีเฟรช AJAX ดังนั้นฉันจึงเริ่มคิดว่าบางทีมันอาจจะมีประสิทธิภาพมากกว่าในการสร้าง API ระดับสูงรอบตรรกะทางธุรกิจของเราอย่างเช่น Amazon Fulfillment API: http://docs.amazonwebservices.com/fws/latest/APIReference/ลูกค้า นักพัฒนาด้านจะใช้เวลามากกว่า UI ในขณะที่นักพัฒนาด้านเซิร์ฟเวอร์จะเน้นเฉพาะตรรกะทางธุรกิจ ดังนั้นสำหรับการสั่งซื้อระบบคุณจะมี API ระดับสูงเช่น: OrderService.asmx CreateOrderResponse CreateOrder(CreateOrderRequest) AddOrderItem AddPayment - SubmitPayment - GetOrderByID FindOrdersByCriteria ... …

9 javascript  architecture  asp.net  team  enterprise-architecture 

พื้นหลัง ฉันกำลังทำการทดสอบปลั๊กอินสำหรับ MS Office โดยอัตโนมัติ เรากำลังสร้างการทดสอบ Coded UI ใน VS 2010 ฉันคิดว่าฉันสามารถใช้เครื่องมือ " Coded UI test builder " แต่มันไม่เหมาะกับกรณีของฉัน ด้วยเหตุนี้ฉันจึงสร้างคลาส UI Map ของฉันเองและวิธีการขยายสำหรับแต่ละ UI Control / Map ที่ฉันเพิ่มฟังก์ชันการทำงานที่แตกต่างกัน ตัวอย่างเช่นกดปุ่มหรือยืนยันค่า UI บางอย่าง สถานการณ์ของกรณีทดสอบอยู่ในคลาสทดสอบ ฉันใหม่ในพื้นที่นี้และฉันยังใหม่ในการทำงานเป็นผู้ทดสอบระบบอัตโนมัติ คำถาม ผู้คนจะใจดีพอที่จะแบ่งปันประสบการณ์และคำแนะนำสำหรับแนวทางปฏิบัติที่ดีสำหรับการทดสอบระบบอัตโนมัติบนแอปพลิเคชันเดสก์ท็อปจากมุมมองการเขียนโปรแกรม / การออกแบบหรือไม่?

9 programming-practices  testing  architecture