我最近一直在玩Entity Framework,WCF RIA Services和Silverlight 4.我对使用这些工具开发应用程序的速度感到印象深刻,并且你获得了很多"免费",例如Silverlight UI自动了解EF模型中作为DataAnnotations包含的某些验证.但是,在大型应用程序中,似乎不希望在整个应用程序(包括业务逻辑和UI)中一直推动EF的依赖.
我知道您可以将POCO/IPOCO与实体框架一起使用,这对我来说无疑是一个选择.但是,如果你走这条路,就会失去一些"自动化"的东西,比如Silverlight能够在没有任何额外工作的情况下显示模型验证.
人们如何处理这个问题？你是否放弃了一些功能并将接口放在不同的层之间,以便将其他层与EF分离？或者你是否放弃了解耦以便更快地发展？有没有办法让我的蛋糕吃掉,我没有看到？
我的小组目前正处理这个问题.我们想出了一个让每个人都满意的妥协方案.请记住,在它结束之前,项目会随着时间的推移变得更加复杂,可维护性是关键.您还希望尽可能地增加代码重用,因此替换UI(或单元测试)是最小化的工作.
鉴于这一切,我们倾向于定义良好的域层,而不是将EF一直推送到UI.这使得模型成为应用程序的核心,并不会强迫我们遵循数据库的模式.我知道EF试图通过它的概念模型来抽象它,但是我们一直在遇到一些小问题,这使得依赖EF完全堆栈变得越来越困难.例如,确实没有一个将业务逻辑与EF放在一起的好地方.我们不想把这些东西放到拦截器中,我们不想把它放在UI中.当然,可能有一个聪明的解决方法,但我们不喜欢我们被推动的方向.
折衷方案是使用EF,但要将其保留在数据存储和域模型之间.这样我们仍然无需针对DataReader进行编程,我们可以利用域中自跟踪实体的优势.然后,我们将基本的WCF服务(不是RESTful)从我们的域暴露给我们的UI.
对我们来说,额外的验证工作并不是真的很重要.当然,我们的初始版本需要花费更多的时间,但整个维护周期并不需要很长时间,因为我们没有完成框架的复杂性.
京公网安备 11010802040832号 | 京ICP备19059560号-6 
