2016-08-12 110 views
0

按照我以前的項目設計師。如何將實體對象與實體框架分開?

  • 業務服務層
    • 業務邏輯在這裏。
    • 可以訪問 「實體」 和 「數據訪問層」
  • 數據訪問層
    • SQL操作在這裏製造。
    • 可以訪問 「實體DTO」
  • 實體層
    • 所有數據庫表DTO在這裏。
  • 表示層
    • 可以訪問企業和實體
    • 無法訪問數據訪問層
    • 查看

現在添加實體框架,我想跟進相同的建築。

  • 業務服務層
    • 業務邏輯在這裏。
    • 可以訪問 「實體」 和 「數據訪問層」
  • 數據訪問層
    • SQL操作在這裏製造。
    • 實體框架下面(的.edmx)
  • 實體層
    • 我想使用實體框架類(EntityObject)在這裏。所以不需要重寫所有的DTO,但要確保CRUD不應該由此完成。不應該包括的ObjectContext /的DbContext
  • 表示層
    • 可以訪問企業和實體
    • 無法訪問數據訪問層(實體框架)
    • 查看
+0

當您調用'dbContext.SaveChanges()'時,會發生CRUD。只要這隻在數據訪問層完成,你應該是好的。 –

+0

@GeorgPatscheider我的意思是上下文不應該存在.. –

+0

但是上下文允許你執行sql操作。在我們的架構中,我們將業務層和數據訪問層(業務邏輯直接與DbContext和實體結合)結合起來。 –

回答

0

有幾件事我想帶出來:

  1. 數據訪問層 - 如果依賴於edmx,那麼您的應用程序將緊密結合使用實體框架。如果可能,創建設計的方式是DAL與實體層作爲抽象對話,而不知道下面實現了哪個ORM(基於接口的設計)。將來您可以用相對較少的努力引入其他ORM。

  2. 爲什麼業務服務層需要引用實體層。理想情況下應該有參考,並且只能訪問DAL。

  3. 與表示層相同的註釋2。

+0

我正在訪問實體填充數據在對象Presenter ..->發送到企業 - >業務做多個業務邏輯轉發實體到DAL - > DAL將做CRUD .. –

+0

實體意味着EF類或它是POCO。演示者和業務人員無法理想地訪問EF類。至少,演示者不能確定。 –

+0

數據訪問層實現必須知道EF,因爲這是它自己的實現細節。從數據層抽象EF毫無意義。檢查圖層的名稱:數據訪問層。 –