我最近一直在研究 Entity Framework 、WCF RIA 服务和 Silverlight 4。使用这些工具开发应用程序的速度之快给我留下了深刻的印象，而且您“免费”获得了很多东西，例如Silverlight UI 自动了解作为 DataAnnotations 包含在 EF 模型中的某些验证。但是，在大型应用程序中，似乎不希望在整个应用程序(包括业务逻辑和 UI)中一直依赖 EF。
我知道您可以将 POCO/IPOCO 与 Entity Framework 一起使用，这对我来说当然是一个选择。然而，如果你走那条路，你会失去一些“自动”的东西，比如 Silverlight 无需任何额外工作就能显示模型验证。
人们如何处理这个问题？为了将其他层与 EF 解耦，您是否会放弃一些功能并在不同层之间放置接口(interface)？还是为了更快速的开发而放弃解耦？有什么方法可以让我的蛋糕也能吃到我没见过的东西吗？
最佳答案
我的小组目前正在处理这个确切的问题。我们想出了一个大家都满意的妥协方案。请记住，在一切都结束之前，项目会随着时间的推移变得更加复杂，而可维护性是关键。您还希望尽可能地提高代码重用率，以便尽可能减少更换 UI(或单元测试)的工作量。
考虑到所有这些，我们倾向于使用定义明确的域层，而不是将 EF 一直推到 UI。这使模型成为应用程序的核心，而不是强制我们遵守数据库的模式。我知道 EF 试图通过其概念模型将其抽象化，但我们不断遇到小陷阱，这使得依赖 EF 获得完整堆栈变得越来越困难。例如，确实没有适合将业务逻辑与 EF 放在一起的好地方。我们不想把那些东西放到拦截器中，我们也不想把它放在 UI 中。当然，可能有一个聪明的解决方法，但我们不喜欢我们被插入的方向。
妥协是使用 EF，但将其保留在数据存储和领域模型之间。这样我们仍然不必针对 DataReader 进行编程，并且我们可以利用域中 self 跟踪实体的优势。然后，我们将域中的基本 WCF 服务(非 RESTful)公开给我们的 UI。
对我们来说，额外的验证工作并不是什么大不了的事。当然，我们的初始版本需要多一点时间，但整个维护周期不会那么长，因为我们没有在框架的复杂性上摆弄。
关于silverlight - 具有 RIA 服务的 Entity Framework ，Silverlight - 解耦与快速开发的权衡，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2864853/