ORM架構：一個或多個模型（實體框架）

Question

場景：

我的工作，有許多組件的解決方案。主要程序集引用具有大型EF模型的DAL程序集。我正在研究一個包含它自己的較小EF模型的DLL。兩種型號都將連接到同一個數據庫。我正在處理的DLL將數據返回到主程序集，但它不一定必須從其模型返回實體。

問：

是它每個子組件包含其自己的小模型或他們都應該共享同一個大模型更好？

討論：

• 一方面，如果我共享的主要組件的模型，子組件可以返回實體的主要組件。
• 另一方面，共享一個大型模型將每個裝配耦合到該模型。看起來這樣會增加更改該模型可能會破壞子程序集的機會。由於害怕破壞其中一個子組件，我可能無法安全地對主模型進行有用的更改。

編輯：

1. 雷Vernagus有大約在你的模型設定明確boundries一些很好的意見（我認爲）。我真的喜歡這個想法。我很有這樣做，因爲我的子部件有一個明確的範圍，因爲在我的部件中有一個單獨的模型。這夠了嗎？

2. 考慮所有域模型都在同一個DAL程序集中，並且許多實體都基於同一個表並具有相同名稱的情況。除了需要在不同的命名空間之外，這會是一個壞主意嗎？

Answer 1

埃裏克埃文斯在他的着作Domain Driven Design中恰當地描述了這種情況。他的建議是圍繞模型設定界限並明確界定它們適用的範圍。這被稱爲Bounded Context和Context Map。

聽起來好像您需要明確您是否希望擁有一個共同的域模型或每個DAL程序集是否應與其自己的模型綁定。如果您需要一箇中央域模型，您可能需要考慮在您的主要程序集中定義此類模型，然後讓您的DAL程序集通過該模型與它進行通信。否則，您可以保留每個DAL程序集的單獨模型，但要定義明確的有界上下文。

希望有幫助！

Answer 2

爲了可維護性原因，我會使用一個大型模型。在任何情況下，當你的模型變化，因爲在該模式中數據庫的變化，你有因此，如果你有一個以上的模型......

Answer 3

我已經使用這兩種類型來傳播這些變化，我相信子模型好得多。特別是完整的模型會很大，不同的子集相對獨立。或者在解決方案的概念性不同部分本地使用。你得到清潔解決方案的集合（能更好地伸縮的複雜性，明智的），你很少有變化是影響幾個概念上不同的系統區域。

最大的問題是，如果你有系統的幾個部分綿延幾個概念領域，因爲它是不平凡的（但可橋接）模式之間跳躍......

BR

丹尼爾