使用RIA服務的實體框架，Silverlight - 解耦與快速開發之間的權衡

Question

我一直在玩Entity Framework，WCF RIA Services和Silverlight 4.最讓我印象深刻的是，用這些應用程序開發應用程序的速度有多快工具，你可以免費獲得很多東西，比如Silverlight UI自動了解EF模型中包含的DataAnnotations的某些驗證。然而，看起來在大型應用程序中，對整個應用程序（包括業務邏輯和用戶界面）一直進行EF依賴關係並不理想。

我知道你可以在實體框架中使用POCO/IPOCO，這對我來說無疑是一種選擇。但是，如果你走這條路，就會失去一些「automagic」的東西，比如Silverlight能夠在沒有任何額外工作的情況下展示模型驗證。

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

Answer 1

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

考慮到所有這些，我們傾向於定義一個良好的域，而不是將EF一直推送到用戶界面。這使模型成爲應用程序的核心，並不會強迫我們遵守數據庫的模式。我知道EF試圖用它的概念模型將它抽象出來，但我們仍然遇到一些小問題，這使得依靠EF來完成整個堆棧變得越來越困難。例如，真的不適合用EF來放置業務邏輯。我們不想將這些東西放到攔截器中，我們也不想將它放入UI中。當然，這可能有一個聰明的解決方法，但我們並不喜歡我們被推動的方向。

妥協方法是使用EF，但將其保留在數據存儲和域模型之間。這樣我們仍然不必針對DataReader進行編程，並且我們可以充分利用域中自我跟蹤實體的優勢。然後，我們將基本的WCF服務（不是RESTful）從我們的域中暴露給我們的UI。

對我們來說，額外的驗證工作並不是什麼大事。當然，我們最初的版本需要更多的時間，但總體維護週期不會持續很長時間，因爲我們並不是在討論框架的複雜性。