GUI, BLL, DAL Organization ในโครงการ

ฉันกำลังอ่านเกี่ยวกับเลเยอร์แอปพลิเคชันและต้องการใช้การออกแบบนี้ในโครงการถัดไปของฉัน (c #, .Net) บางคำถาม:

1. การแยกเลเยอร์ทำได้ผ่านเนมสเปซหรือไม่ โครงการ. BLL. สิ่งที่โครงการ. Dal. สิ่งที่

2. มันเหมาะสมกว่าที่จะแยกโดยเลเยอร์แล้วส่วนประกอบ (Project.BLL.Component1) หรือโดยส่วนประกอบแล้วเลเยอร์ (Project.Component1.BLL)

3. สำหรับ DAL ของฉันเลเยอร์นี้มีการจัดระเบียบเพิ่มเติมโดยใช้คลาสอื่นหรือไม่ ถ้าการเรียกฐานข้อมูลทั้งหมดถูกใส่ในคลาสเดียวก็จะไม่มีองค์กรใด มันจะดีกว่าไหมที่จะแยกมันออกเป็นคลาสหรือเนมสเปซที่ต่างกัน?

4. คลาส DAL เป็นแบบสแตติกหรือไม่ ดูเหมือนว่ายุ่งยากในการยกตัวอย่างวัตถุ DAL ก่อนที่จะเรียกใช้หนึ่งในวิธีการในแต่ละครั้ง

เคล็ดลับอื่น ๆ สำหรับการทำสิ่งต่าง ๆ ด้วยวิธีที่ถูกต้องกับเลเยอร์เหล่านี้จะได้รับการชื่นชม

1. ใช่. และยังประกอบ
2. ฉันแยกชั้นแล้วส่วนประกอบ
3. ใช่. มีวิธีที่แตกต่างกันในการนี้ แต่ฉันมี IDatabaseService (สรุปมารยาทต่างๆในฐานข้อมูลที่เรียกว่า - นี้สามารถเกือบจะเป็นการทำแผนที่โดยตรงของ ExecuteScalar / ExecuteNonQuery / ExecuteReader) แล้วการเรียนการเข้าถึงข้อมูลต่างๆที่ พาร์ทิชันตามประเภทของข้อมูล ตัวอย่างเช่นคุณอาจมีคลาส UserDataAccess ที่จะมีวิธีการ CRUD อย่างง่าย ๆ ที่สร้าง / แก้ไข / ลบวัตถุผู้ใช้ อีกวิธีหนึ่งคือการมีวัตถุผู้ใช้ที่มี CRUD อยู่ในตัว

4. ฉบับที่ทำให้มันมากยากที่จะทดสอบหน่วย คุณควรใช้การฉีดพึ่งพาเพื่อส่งผ่านการอ้างอิงไปยังตัวสร้างของคลาสการเข้าถึงข้อมูลแต่ละคลาส (เช่น IDatabaseService) จากนั้นคุณจะส่งวัตถุการเข้าถึงข้อมูลไปยังวัตถุทางธุรกิจเช่นนี้

   BusinessObject businessObject = ใหม่ BusinessObject (ใหม่ DataAccessObject (ใหม่ DatabaseService ())); businessObject.PerformOperation ();

แต่ละวัตถุธุรกิจอาจต้องการวัตถุการเข้าถึงข้อมูลหลายรายการ รหัส GUI ของคุณจะใช้วัตถุธุรกิจอย่างน้อยหนึ่งรายการ วัตถุทางธุรกิจบางอย่างอาจไม่ต้องการวัตถุการเข้าถึงข้อมูลใด ๆ แต่ไม่ควรใช้ IDatabaseService โดยตรง

สำหรับคำถามที่ 1 และ 2 ไปกับคำตอบของมัทธิว

ฉันใช้เวลามากในการพยายามหาวิธีที่ดีที่สุดในการจัดโครงสร้าง DAL ของแอปพลิเคชันเดสก์ท็อป และวิธีที่ดีที่สุดขึ้นอยู่กับความต้องการของแอปพลิเคชัน ในหนึ่งในแอพของฉันฉันลงไปบนถนนที่มีคลาส DA สำหรับแต่ละตารางฐานข้อมูลซึ่งลงทะเบียนตัวเองด้วยคลาส DataProvider (เช่นซิงเกิล) ส่วนกลางและจัดการ CRUD แต่ละคลาส DA สามารถตัดสินใจได้ว่าต้องการแคชข้อมูลตารางทั้งหมดใน RAM หรือไม่ (ประสิทธิภาพ!) และ / หรือจำเป็นต้องมีความสามารถในการเรียกใช้การอัพเดตไคลเอ็นต์อัตโนมัติในไคลเอนต์อื่นที่รันบนคอมพิวเตอร์เครื่องอื่น (คิดว่าหลายผู้ใช้ เห็นพ้องด้วย) สิ่งนี้ทำให้ง่ายต่อการเพิ่มคลาส DAL ใหม่เนื่องจากสิ่งที่พวกเขาต้องทำคือทำตามอินเตอร์เฟสการลงทะเบียน

ไม่ใช่ทุก DAL ที่ต้องการฟังก์ชั่นประเภทนี้ แต่ฉันได้เรียนรู้ว่าวิธีการของตัวเอง (เช่นผู้ให้บริการข้อมูลเดี่ยวและคลาส DAL ง่าย ๆ ที่มีการลงทะเบียนแบบคงที่) ทำให้ชีวิตของฉันง่ายขึ้นมากเมื่อฉันเริ่มเพิ่มคลาสใหม่

ฉันจะไม่แนะนำให้สร้าง CRUD ลงในคลาสระดับสูงกว่านี้เว้นแต่จะเป็นแอปพลิเคชันที่ง่ายมาก DAL เป็นนามธรรมของการจัดเก็บข้อมูล หากคุณตัดสินใจที่จะเปลี่ยนการจัดเก็บข้อมูลของคุณในบางจุดในอนาคต (แม้ว่าจะเป็นเพียงการใช้ MySQL แทน MS SQL) คุณจะรู้สึกขอบคุณอย่างมาก บวก: วัตถุ BLL ควรจัดโครงสร้างตามความสัมพันธ์เชิงตรรกะทางธุรกิจ วัตถุ DAL ถูกจัดโครงสร้างตามชนิดของคอนเทนเนอร์ที่เก็บข้อมูลที่เป็นตัวแทน ความแตกต่างได้อย่างมาก

อย่าไม่ให้เรียน DAL ของคุณคงที่ สิ่งที่คุณได้รับจากความเร็วในการเข้ารหัสคุณจะสูญเสียหลาย ๆ ครั้งในการทดสอบและความยืดหยุ่น