Entity Framework และการแยกชั้น


12

ฉันพยายามทำงานกับ 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 ของฉันไว้ในห้องสมุดของตัวเองหรือจะดีกว่าถ้าวางมันไว้ใน BLL ของฉันและทำงานที่นั่น?

ฉันไม่เห็นเหตุผลที่จะห่อ EF เข้าไปใน DAL ของฉันเอง แต่ฉันอยากรู้ว่าคนอื่นกำลังทำอะไร

ดังนั้นแทนที่จะมีข้างต้นฉันจะออกจาก DAL และเพียงทำ:

BLL:

GetPerson(id)
{
    using (TestEntities context = new TestEntities())
    {
            var result = from p in context.Persons.Where(p => p.Id = id)            
                    select p;
    }
}

จะทำอย่างไร?

คำตอบ:


13

ตัวอย่างที่คุณระบุเป็นสถาปัตยกรรมที่แทบจะไม่มี ฉันรู้ว่ามันง่ายขึ้นโดยเจตนา แต่:

เลเยอร์การนำเสนอของคุณเชื่อมโยงโดยตรงกับเอนทิตีบุคคล สิ่งนี้ใช้ได้ในกรณีที่ง่ายที่สุดเท่านั้นและไม่แน่นอนเมื่อคุณพยายามกำหนดเลเยอร์ของคุณ

กระบวนการ GetPerson ยังใช้วิธีปฏิบัติที่ค่อนข้างแย่ในการสร้างบริบทใหม่สำหรับการโทรแต่ละครั้ง คุณควรรับบริบทใน Constructor และมันจะถูกจัดเตรียมโดยคอนเทนเนอร์ IOC ของคุณ

โครงสร้างที่เรียบง่าย แต่มีประสิทธิภาพที่ฉันใช้คือ:

  • Project.Core - มีรูปแบบการดูและการเชื่อมต่อ
  • Project.DAL - ด้วย EDMX ของฉันและสร้างรหัส
  • Project.BLL - ตรรกะทางธุรกิจ
  • Project.Web - เว็บแอปนั้น ๆ

เป็นสิ่งสำคัญที่จะต้องทราบว่า:

  • แกนหลักไม่ได้ขึ้นอยู่กับโซลูชันอื่นใด ๆ
  • DAL ไม่ได้ขึ้นอยู่กับโซลูชันอื่นใด ๆ
  • Project.Web ขึ้นอยู่กับ Core แต่ไม่ใช่ใน DAL หรือ BLL
  • BLL ขึ้นอยู่กับ Core และ DAL

1
แกนจะปรากฏเป็นเลเยอร์วัตถุธุรกิจ
sq33G

นี่เป็นสิ่งที่ฉันใช้ด้วยอย่างไรก็ตามฉันจะเพิ่ม DLLs พิเศษเพื่อรองรับการประกาศส่วนต่อประสาน วิธีนี้คุณอ้างถึงส่วนต่อประสาน (และใช้บางอย่างเช่น [url = unity.codeplex.com/ เหมือน Unityurl/ url ]สำหรับ DI) และคุณสามารถมั่นใจได้ว่าไม่มีการอ้างอิงแปลก ๆ ที่คุณได้ตั้งใจ
Ed James

โดยปกติถ้าไม่มี EF ฉันจะสร้างคลาส Person ของฉันเองในเลเยอร์ "Model" ดังนั้นฉันจึงมี UI, BLL, DAL และ Model โดยที่: UI รู้จัก BLL และ Model BLL รู้จัก DAL และรุ่น DLL รู้รุ่น คุณสร้าง "มุมมองแบบจำลอง" ของคุณเองและทำไมคุณไม่ใช้สิ่งที่ EF สร้างขึ้นมา? (ฉันรู้ว่านี้ไปกับสถาปัตยกรรมชั้น แต่คุณไม่กี่ครั้งที่จริงเปลี่ยนวิธีที่คุณจะได้รับข้อมูล?)
โทมัส

@ โทมัสการห่อโมเดลมุมมองในสิ่งที่เป็นนามธรรมจะทำให้การทดสอบหน่วยนั้นง่ายขึ้นมาก
sq33G

3
model! = ดู model
Boris Yankov

2

คุณไม่จำเป็นต้องห่อ EDMX ของคุณในสิ่งใด

หากคุณสามารถเห็นความเป็นไปได้ที่จะต้องเปลี่ยนจาก EF เป็นแนวทางอื่นคุณอาจต้องการขยายวัตถุธุรกิจของคุณ (ใช้ประโยชน์จากคลาสบางส่วน) เพื่อนำอินเตอร์เฟสที่กำหนดไว้ในเลเยอร์วัตถุธุรกิจแยกต่างหาก

จากรหัสของคุณคุณจะจัดการกับอินเทอร์เฟซเหล่านั้นเท่านั้นไม่ใช่กับคลาสที่สร้างขึ้นอย่างเป็นรูปธรรม อาจจำเป็นต้องใช้รหัสกาวเล็กน้อยเพื่อเก็บสิ่งนี้เข้าด้วยกัน ด้วย EDMX สามารถเป็น DAL ของคุณได้


ดังนั้นถ้าฉันไม่ยกเลิกการเปลี่ยนแปลงใด ๆ จาก EF เป็นแนวทางอื่นรหัสของฉันด้านบนจะไม่เป็นไร ฉันจะมีเฉพาะ UI และ BLL (ที่ EDMX อยู่ใน BLL) เท่านั้น
โทมัส

คำตอบในทางปฏิบัติของฉันจะเป็นใช่ ด้วยข้อแม้ที่คุณอาจต้องการวาง EDMX ลงในแอสเซมบลีตัวเล็ก ๆ ของตัวเองถ้ามันมีขนาดใหญ่และคงที่ส่วนใหญ่เพื่อที่คุณจะไม่ต้องคอมไพล์ซ้ำ / แจกจ่ายซ้ำบ่อยครั้ง
sq33G

อาจุดที่ดีเกี่ยวกับการคอมไพล์ / แจกจ่าย :)
โทมัส

2

มีสองวิธีทั่วไปในการฝังรากลึก: ฝังรากลึกอย่างเข้มงวดและฝังรากลึกชั้นผ่อนคลาย

วิธีการเรียงลำดับชั้นอย่างเข้มงวด จำกัด ส่วนประกอบในชั้นหนึ่งเพื่อโต้ตอบเฉพาะกับเพื่อนและกับชั้นด้านล่างโดยตรง

แอพพลิเคชั่นแบบเลเยอร์ที่ผ่อนคลายช่วยคลายข้อ จำกัด เช่นที่ส่วนประกอบสามารถโต้ตอบกับส่วนประกอบจากชั้นล่าง ๆ

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

สำหรับโซลูชันขนาดใหญ่ที่เกี่ยวข้องกับส่วนประกอบซอฟต์แวร์จำนวนมากเป็นเรื่องปกติที่จะมีส่วนประกอบจำนวนมากในระดับที่เป็นนามธรรมซึ่งไม่ได้เชื่อมติดกัน ในกรณีนี้แต่ละเลเยอร์อาจถูกย่อยสลายต่อไปในระบบย่อยหนึ่งระบบหรือมากกว่า รูปที่ 2 แสดงสัญลักษณ์ Unified Modeling Language (UML) ที่เป็นไปได้สำหรับการแสดงเลเยอร์ที่ประกอบด้วยระบบย่อยหลายระบบ

ข้อสรุป: ถ้าคุณไม่ต้องการให้คนชั้นกลางเสีย ไม่ใช่ทุกแอพพลิเคชั่นที่ต้องการวิธีการเดียวกันและการเพิ่มเลเยอร์เพื่อจุดประสงค์ในการจัดวางจะมีบทลงโทษสำหรับค่าใช้จ่ายและการบำรุงรักษาที่ซับซ้อน

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.