我有一個關於WPF MVVM應用程序開發框架PRISM幾個問題：在一個模塊化的應用程序一些建築和設計指導有關PRISM和WPF
如若模塊包含數據訪問代碼？
如果模塊依賴於基礎設施項目中存在的代碼，例如棱鏡文檔中的「股票交易者RI」，那麼這不會導致這些模塊與基礎之間的緊密耦合。項目，不是模塊假設是自包含的功能！？我喜歡所有代碼都應該依賴於業務邏輯層的DDD（域驅動開發）神話，因此沒有「依賴箭頭」應該離開BLL，而是應該進入BLL（例如， DAL依賴於BLL中的接口，然後你可以使用一個DI容器來連接所有的東西），我認爲這些模塊是應用程序的BLL，所以我不希望它們依賴於任何東西，你是否可以實現它模塊化PRISM應用程序（如何）？
是的，因爲一個棱鏡應用程序通常只由模塊，然後如果你想在你的應用程序訪問的數據，你將不得不從模塊訪問它以某種方式。
管理依賴關係很重要。我嘗試檢查我的模塊做什麼以決定是否有意義參考我的基礎設施項目。例如，如果您正在創建事件記錄模塊，則可能需要考慮將該接口放入不是您的基礎架構項目的公共庫中，因爲您可能會將其重用於其他項目。但是，我不介意引用基礎結構項目的項目特定模塊。這些模塊仍然允許我強制實現鬆耦合，隨意更換模塊以添加或刪除功能，或者如果我將應用程序水平而不是垂直地切片，則交換UI。
我不太清楚你的意思是不依賴於「任何東西」。我想他們仍然依賴.NET核心庫。那麼棱晶呢？這是允許的嗎？如果您關心他們引用Prism或您的基礎架構項目，您可以始終將BLL代碼放在單獨的DLLS中，以便模塊引用和實現模型存儲庫，查看模型邏輯並查看其內部的邏輯。
我大多同意你的第一個答案，關於第二個問題，如果你把日誌記錄或認證或其他「交叉關注」放在一個共享庫中，並使BLL依賴於它，那不會產生緊密耦合，我認爲使用在這種情況下，DI容器的攔截機制將有很大幫助。現在對於最後一部分，你是對的，代碼應該至少依賴於.NET框架或棱鏡，但是我認爲這些是「穩定的依賴關係」（根據Mark Seemann的書，他們不會經常改變） .NET中的依賴注入，這沒關係。 –
如果您希望業務邏輯包含日誌記錄，那麼它必須引用包含該接口的庫，而不一定是實現。由於您的日誌記錄界面可能是可重用的，因此我可能會考慮將其放入可在組織內重用的庫中。要麼是這個，要麼必須進入基礎設施項目。例如，實現可以在其他地方作爲一個單獨的模塊，如果您希望它不依賴於該項目，可以嘗試避免參考基礎架構項目。 – Alan
謝謝。我認爲你和我同意這個解決方案。但似乎我只是不喜歡棱鏡應用程序組成的方式。無論如何，這是一個私人問題。所以我會認爲你的答案是正確的。 –
如果您更具體地說明您希望在特定問題域中完成什麼，這可能會很有用。儘可能鬆散的耦合將傳遞一個簡單的數據對象，但顯然這對你的應用程序來說並不會很有用，除非你可以通過將其轉換爲某些API，比如'ViewModel'類或接口。 –
另外，你應該閱讀關於鬆散耦合的維基百科文章。它說，*「當依賴類僅包含一個指向接口的指針時，就會發生鬆耦合，這個指針可以由一個或多個具體類來實現，依賴類的依賴關係是由接口指定的」契約「，一個定義好的列表實現類必須提供的方法和/或屬性，任何實現接口的類都可以滿足依賴類的依賴性，而不必更改類。「* –
@RobertHarvey我不能更具體，因爲我問了一個最近更具體的問題，但沒有得到答案。我知道接口施加合同並提供鬆散耦合，但DDD的依賴性視圖使您能夠將BLL隔離爲具有公共接口的可重用庫，然後應用程序中的所有其他圖層依賴於這些庫。我希望我能提供一個例子，但它不適合這裏。如果可能的話，我希望你對第一個問題的看法特別重要。 –