帶有RIA服務的實體框架，Silverlight - 脫鈎與快速開發的權衡

Question

我最近一直在玩Entity Framework，WCF RIA Services和Silverlight 4.我對使用這些工具開發應用程序的速度感到印象深刻，並且你獲得了很多“免費”，例如Silverlight UI自動了解EF模型中作為DataAnnotations包含的某些驗證。 但是，在大型應用程序中，似乎不希望在整個應用程序（包括業務邏輯和UI）中一直推動EF的依賴。

我知道您可以將POCO / IPOCO與實體框架一起使用，這對我來說無疑是一個選擇。 但是，如果你走這條路，就會失去一些“自動化”的東西，比如Silverlight能夠在沒有任何額外工作的情況下顯示模型驗證。

人們如何處理這個問題？ 你是否放棄了一些功能並將接口放在不同的層之間，以便將其他層與EF分離？ 或者你是否放棄了解耦以便更快地發展？ 有沒有辦法讓我的蛋糕吃掉，我沒有看到？

Answer 1

我的小組目前正處理這個問題。 我們想出了一個讓每個人都滿意的妥協方案。 請記住，在它結束之前，項目會隨着時間的推移變得更加復雜，可維護性是關鍵。 您還希望盡可能地增加代碼重用，因此更換UI（或單元測試）的工作量最小化。

鑒於這一切，我們傾向於定義良好的域層，而不是將EF一直推送到UI。 這使得模型成為應用程序的核心，並不會強迫我們遵循數據庫的模式。 我知道EF試圖通過它的概念模型來抽象它，但是我們一直在遇到一些小問題，這使得依賴EF完全堆棧變得越來越困難。 例如，確實沒有一個將業務邏輯與EF放在一起的好地方。 我們不想把這些東西放到攔截器中，我們不想把它放在UI中。 當然，可能有一個聰明的解決方法，但我們不喜歡我們被推動的方向。

折衷方案是使用EF，但要將其保留在數據存儲和域模型之間。 這樣我們仍然無需針對DataReader進行編程，我們可以利用域中自跟蹤實體的優勢。 然后，我們將基本的WCF服務（不是RESTful）從我們的域暴露給我們的UI。

對我們來說，額外的驗證工作並不是真的很重要。 當然，我們的初始版本需要花費更多的時間，但整個維護周期並不需要很長時間，因為我們沒有完成框架的復雜性。