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

สถานการณ์ เมื่อเช้านี้ฉันตอบคำถามใน StackOverflow คำถาม: การแก้ไขวัตถุที่มีอยู่ควรทำในพื้นที่เก็บข้อมูลเลเยอร์หรือบริการ? ตัวอย่างเช่นถ้าฉันมีผู้ใช้ที่มีหนี้ ฉันต้องการเปลี่ยนหนี้ของเขา ฉันควรทำมันใน UserRepository หรือในการให้บริการเช่น BuyingService โดยรับวัตถุแก้ไขและบันทึกมันได้หรือไม่ คำตอบของฉัน: คุณควรปล่อยให้ความรับผิดชอบในการกลายวัตถุเป็นวัตถุเดียวกันนั้นและใช้ที่เก็บเพื่อดึงข้อมูลวัตถุนี้ สถานการณ์ตัวอย่าง: class User { private int debt; // debt in cents private string name; // getters public void makePayment(int cents){ debt -= cents; } } class UserRepository { public User GetUserByName(string name){ // Get appropriate user …

397 design-patterns  layers 

ในแอปพลิเคชันเว็บ MVC ทั่วไป (ออกแบบมาอย่างดี) ฐานข้อมูลไม่ทราบรหัสรุ่นรหัสรุ่นไม่ทราบรหัสคอนโทรลเลอร์และรหัสควบคุมไม่ทราบรหัสมุมมอง (ฉันคิดว่าคุณสามารถเริ่มได้ไกลถึงฮาร์ดแวร์หรืออาจจะยิ่งกว่านั้นอีกและรูปแบบอาจเหมือนกัน) ไปอีกทิศทางหนึ่งคุณสามารถลงไปหนึ่งชั้น มุมมองสามารถรับรู้ถึงคอนโทรลเลอร์ แต่ไม่ใช่โมเดล คอนโทรลเลอร์สามารถรับรู้ถึงโมเดล แต่ไม่ใช่ฐานข้อมูล รูปแบบสามารถรับรู้ถึงฐานข้อมูล แต่ไม่ใช่ระบบปฏิบัติการ (อะไรที่ลึกกว่านั้นอาจไม่เกี่ยวข้อง) ฉันสามารถเข้าใจได้อย่างสังหรณ์ใจว่าทำไมนี่เป็นความคิดที่ดี แต่ฉันไม่สามารถพูดได้ ทำไมรูปแบบทิศทางเดียวของการวางแนวคิดที่ดีนี้

66 architecture  mvc  encapsulation  layers 

พื้นหลัง : ฉันกำลังพยายามใช้สถาปัตยกรรมที่สะอาดของลุงบ็อบในแอพ Android ของฉัน ฉันศึกษาโครงการโอเพนซอร์ซจำนวนมากที่พยายามแสดงวิธีการที่ถูกต้องและฉันพบว่ามีการนำไปใช้ที่น่าสนใจโดยใช้ RxAndroid สิ่งที่ฉันสังเกตเห็น: ในทุกเลเยอร์ (งานนำเสนอโดเมนและข้อมูล) มีคลาสโมเดลสำหรับเอนทิตีเดียวกัน (พูดถึง UML) นอกจากนี้ยังมีคลาส mapper ที่ดูแลการเปลี่ยนแปลงของวัตถุเมื่อใดก็ตามที่ข้อมูลข้ามเขตแดน (จากชั้นหนึ่งไปอีกชั้นหนึ่ง) คำถาม: มันจำเป็นต้องมีคลาสของโมเดลในทุกเลเยอร์หรือไม่เมื่อฉันรู้ว่าพวกมันทั้งหมดจะจบลงด้วยคุณลักษณะเดียวกันหากจำเป็นต้องใช้การดำเนินการ CRUD ทั้งหมดหรือไม่ หรือว่าเป็นกฎหรือแนวปฏิบัติที่ดีที่สุดเมื่อใช้สถาปัตยกรรมสะอาดหรือไม่

44 java  architecture  android  clean-code  layers 

เพื่อนร่วมงานของฉันบางคนบอกว่าการมีตรรกะทางธุรกิจในขั้นตอนการจัดเก็บในฐานข้อมูลเป็นการละเมิดสถาปัตยกรรมการแยกสามระดับเนื่องจากฐานข้อมูลเป็นของชั้นข้อมูลในขณะที่ขั้นตอนการจัดเก็บเป็นตรรกะทางธุรกิจ ฉันคิดว่าโลกจะเป็นสถานที่ที่น่ากลัวมากโดยไม่มีขั้นตอนการจัดเก็บ พวกเขาละเมิดการแยกแบบสามระดับจริง ๆ หรือไม่

41 business-logic  n-tier  layers  stored-procedures  separation-of-concerns 

มันเหมาะสมหรือไม่ที่จะใช้ ORM ในการพัฒนา Android หรือเป็นเฟรมเวิร์กที่เหมาะสำหรับการเชื่อมต่อที่แน่นขึ้นระหว่าง UI และเลเยอร์ DB หรือไม่? ความเป็นมา : ฉันเพิ่งเริ่มต้นด้วยการพัฒนา Android และสัญชาตญาณแรกของฉัน (มาจากพื้นหลัง. net) คือการมองหา mapper เชิงสัมพันธ์วัตถุขนาดเล็กและเครื่องมืออื่น ๆ ที่ช่วยลด clode สำเร็จรูป (เช่น POJOs + OrmLite + Lombok ) อย่างไรก็ตามในขณะที่พัฒนาโปรแกรมประยุกต์ของเล่นครั้งแรกของฉันฉัน stumbled เมื่อชั้น UI AlphabetIndexerอย่างชัดเจนว่าต้องใช้เคอร์เซอร์ฐานข้อมูล: นั่นทำให้ฉันสงสัยว่าบางทีห้องสมุด Android อาจไม่เหมาะกับการแยก UI และเลเยอร์ DB อย่างเข้มงวดและฉันจะพลาดคุณสมบัติที่มีประโยชน์และประหยัดเวลามากมายถ้าฉันพยายามใช้ POJO ทุกที่ (แทนที่จะเข้าถึงฐานข้อมูลโดยตรง) ) ชี้แจง : ฉันค่อนข้างตระหนักถึงข้อดีของการใช้ ORM …

27 android  orm  layers  android-development 

แนวโน้มในการออกแบบและพัฒนาแอพพลิเคชั่นดูเหมือนจะเริ่มต้นด้วย "ความกล้า": โดเมนจากนั้นเข้าถึงข้อมูลจากนั้นก็เป็นโครงสร้างพื้นฐานเป็นต้น GUI ดูเหมือนว่าโดยปกติจะมาในภายหลัง ฉันสงสัยว่ามันจะมีประโยชน์ในการสร้าง GUI ก่อนหรือไม่ เหตุผลของฉันคือการสร้าง GUI ต้นแบบอย่างน้อยคุณจะได้ความคิดที่ดีขึ้นเกี่ยวกับสิ่งที่ต้องเกิดขึ้นเบื้องหลังและดังนั้นจึงอยู่ในตำแหน่งที่ดีกว่าในการเริ่มทำงานในโดเมนและรหัสการสนับสนุน ฉันสามารถเห็นปัญหาของการฝึกนี้ในกรณีที่ยังไม่ได้เขียนโค้ดที่รองรับมันจะไม่มีอะไรมากสำหรับเลเยอร์ GUI ที่ต้องทำจริง ๆ บางทีการสร้างวัตถุจำลองหรือชั้นเรียนที่ถูกโยนทิ้ง (คล้ายจะทำในการทดสอบหน่วย) อาจให้พื้นฐานที่เพียงพอในการสร้าง GUI ในตอนแรก อาจเป็นความคิดที่เป็นไปได้สำหรับโครงการจริงหรือ บางทีเราอาจเพิ่ม GDD (การพัฒนา GUI ขับเคลื่อนด้วย) ไปยังตัวย่อที่เสถียร ...

17 gui  application-design  layers 

ฉันรู้ว่าคุณกำลังคิด (หรืออาจจะตะโกน), "ไม่ใช่คำถามที่ถามอีกว่าการตรวจสอบเป็นของสถาปัตยกรรมชั้นหรือไม่?" ใช่แล้ว แต่หวังว่านี่จะเป็นเรื่องที่ต่างออกไปเล็กน้อย ฉันเชื่อมั่นว่าการตรวจสอบมีหลายรูปแบบตามบริบทและแตกต่างกันไปในแต่ละระดับของสถาปัตยกรรม นั่นเป็นพื้นฐานสำหรับการโพสต์ช่วยระบุประเภทของการตรวจสอบที่ควรดำเนินการในแต่ละชั้น นอกจากนี้คำถามที่มักเกิดขึ้นก็คือการตรวจสอบสิทธิ์ สถานการณ์ตัวอย่างมาจากแอปพลิเคชันสำหรับธุรกิจจัดเลี้ยง ในระหว่างวันผู้ขับขี่อาจเปลี่ยนเป็นเงินสดส่วนเกินที่พวกเขาสะสมไว้ในสำนักงานขณะนำรถบรรทุกจากที่หนึ่งไปยังอีกที่หนึ่ง แอปพลิเคชั่นอนุญาตให้ผู้ใช้บันทึก 'เงินสดลดลง' โดยการรวบรวม ID ของไดรเวอร์และจำนวนเงิน นี่คือรหัสโครงกระดูกบางส่วนเพื่อแสดงเลเยอร์ที่เกี่ยวข้อง: public class CashDropApi // This is in the Service Facade Layer { [WebInvoke(Method = "POST")] public void AddCashDrop(NewCashDropContract contract) { // 1 Service.AddCashDrop(contract.Amount, contract.DriverId); } } public class CashDropService // This is the Application …

13 domain-driven-design  validation  layers 

เมื่อพิจารณาถึงซอฟต์แวร์ขนาดกลางขนาดใหญ่ที่มีสถาปัตยกรรมแบบเลเยอร์ n และการฉีดขึ้นต่อกันฉันรู้สึกสบายใจที่จะพูดว่าวัตถุที่เป็นของเลเยอร์สามารถพึ่งพาวัตถุจากเลเยอร์ที่ต่ำกว่า แต่ฉันไม่แน่ใจว่าจะคิดอย่างไรเกี่ยวกับวัตถุที่ขึ้นอยู่กับวัตถุอื่นของเลเยอร์เดียวกัน ตัวอย่างเช่นสมมติว่าแอปพลิเคชันที่มีสามชั้นและวัตถุหลายอย่างเช่นหนึ่งในภาพ เห็นได้ชัดว่าการพึ่งพาจากบนลงล่าง (ลูกศรสีเขียว) ก็โอเคการเติมเงิน (ลูกศรสีแดง) ไม่เป็นไร แต่การพึ่งพาในเลเยอร์เดียวกัน (ลูกศรสีเหลือง) เป็นอย่างไร ไม่รวมการพึ่งพาอาศัยกันแบบวงกลมฉันอยากรู้เกี่ยวกับปัญหาอื่น ๆ ที่อาจเกิดขึ้นและสถาปัตยกรรมของชั้นที่ถูกละเมิดในกรณีนี้

12 architecture  dependencies  layers 

ฉันพยายามทำงานกับ Entity Framework เล็กน้อยและฉันมีคำถามเกี่ยวกับการแยกชั้น ฉันมักจะใช้ UI -> BLL -> วิธี DAL และฉันสงสัยว่าจะใช้ภาษา EF ที่นี่ได้อย่างไร DAL ของฉันมักจะเป็นอะไรที่ชอบ GetPerson(id) { // some sql return new Person(...) } BLL: GetPerson(id) { Return personDL.GetPerson(id) } UI: Person p = personBL.GetPerson(id) คำถามของฉันคือ: เนื่องจาก EF สร้างแบบจำลองและ DAL ของฉันมันเป็นความคิดที่ดีหรือไม่ที่จะห่อ EF ไว้ใน DAL ของฉันเองหรือแค่เสียเวลา? ถ้าฉันไม่ต้องการห่อ EF ฉันจะยังคงวาง Model.esmx …

12 c#  entity-framework  layers 

ฉันเห็นเฉพาะประโยชน์ของสถาปัตยกรรมหัวหอมเหนือสถาปัตยกรรม 3 ชั้นที่ BL มีความรับผิดชอบในการเรียกใช้เมธอดบน DAL (หรืออินเตอร์เฟสของ DAL) เพื่อทำ CRUD หัวหอมมีการแยกความกังวลการทดสอบการบำรุงรักษาที่ดีขึ้นและสะอาดขึ้น ดังนั้นสถาปัตยกรรมหัวหอมจึงดีกว่าในทุกด้านและสถาปัตยกรรมแบบ 3 ชั้นเป็นเพียงวิธีเก่า ๆ ในการทำสิ่งต่าง ๆ หรือมีบางสถานการณ์ที่ฉันควรจะใช้สถาปัตยกรรมแบบ 3 ชั้นถ้าเป็นเช่นนั้น

11 design  architecture  layers  n-tier  onion-architecture 

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

9 architecture  domain-driven-design  layers 

ฉันกำลังอ่านเกี่ยวกับเลเยอร์แอปพลิเคชันและต้องการใช้การออกแบบนี้ในโครงการถัดไปของฉัน (c #, .Net) บางคำถาม: การแยกเลเยอร์ทำได้ผ่านเนมสเปซหรือไม่ โครงการ. BLL. สิ่งที่โครงการ. Dal. สิ่งที่ มันเหมาะสมกว่าที่จะแยกโดยเลเยอร์แล้วส่วนประกอบ (Project.BLL.Component1) หรือโดยส่วนประกอบแล้วเลเยอร์ (Project.Component1.BLL) สำหรับ DAL ของฉันเลเยอร์นี้มีการจัดระเบียบเพิ่มเติมโดยใช้คลาสอื่นหรือไม่ ถ้าการเรียกฐานข้อมูลทั้งหมดถูกใส่ในคลาสเดียวก็จะไม่มีองค์กรใด มันจะดีกว่าไหมที่จะแยกมันออกเป็นคลาสหรือเนมสเปซที่ต่างกัน? คลาส DAL เป็นแบบสแตติกหรือไม่ ดูเหมือนว่ายุ่งยากในการยกตัวอย่างวัตถุ DAL ก่อนที่จะเรียกใช้หนึ่งในวิธีการในแต่ละครั้ง เคล็ดลับอื่น ๆ สำหรับการทำสิ่งต่าง ๆ ด้วยวิธีที่ถูกต้องกับเลเยอร์เหล่านี้จะได้รับการชื่นชม

9 c#  code-organization  layers