我在解決方案中有三層：數據訪問（DA），業務邏輯（BL）和WCF契約邏輯（CL） - 按順序堆疊。通過層傳遞類型
在DA中存儲了一個實體框架模型，其中包含一個類型爲SQL的表格。我想要在CL中訪問這種類型的堆棧，但我不想犯下不切實際的做法，讓CL直接與DA進行交談，而是將CL指向BL，將BL指向DA--如果這樣做有道理。最簡單的前進方式是合併BL和CL層，但假設我想在我的解決方案中保留指定的分離，我怎麼能實現我之前說過的？
我曾想過以下解決方案：
上述解決方案的問題是，如果更新發生在DL中的類型中，CL中的接口不再是真實的並且可能會中斷應用程序。我想要一個自動更新所有圖層而無需人工干預的解決方案。
任何真棒建議？
您需要實現誰將會在所有其他層引用第四層（例如：公共層）。您將在其中定義您將在應用程序中使用的類型。
Here 是一篇很好的文章，解釋您可以使用的不同方法。
解決方案可能是第四層：模型層。該模型包含所有您希望用作POCO類的類。由於它們是POCO類，所以它們不依賴於EF。如果你願意，你可以用DataMember和DataContract來裝飾它們。這不是最好的解決方案，但我認爲這不會打破抽象或泄漏它，如果你想DataContract作爲Serializable的替代方案（當然，你可以把它提升到一個新的水平並編寫序列化代理，但這是相當大量的工作）。請注意，模型不依賴於WCF，因爲這些類型位於System.Runtime.Serialization程序集中，而不是ServiceModel程序集（當然，也不依賴於EF）。
從DAL引用模型。在DAL中，您可以創建EF DbContext（禁用延遲加載和代理生成），將EntityTypeConfigurations添加到流暢的API中，依此類推。
然後繼續並從BLL和契約層中引用它們。
這樣你就擁有了一個帶有POCO類的單一統一模型層，除了可疑的序列化屬性之外，它是技術不可知的。
請勿實施您詳細說明的3個選項中的任何一個。 正如上面的人已經表示了一個包含DTO或Pocos的共同程序集，以及可能被所有圖層使用的接口契約。
我會建議在圖層之間的接口中使用DTO或Pocos，以及用於穿梭數據。 具有良好示例的好文檔 https://docs.microsoft.com/en-us/aspnet/web-api/overview/data/using-web-api-with-entity-framework/part-5
您的實體應該是您的域模型的一部分，例如業務層。任何其他層都可以引用業務層，而不是其他方式。因此，請將數據層引用業務層 - 將EF實體放入業務層。請參閱http://jeffreypalermo.com/blog/the-onion-architecture-part-1/ – Maarten
除了下面的答案之外，我還建議您使用automapper將EF實體轉換爲業務邏輯中的DTO（數據傳輸對象）。您的WCF服務的使用者一定不知道您的EF實體。 –