我正在针对遗留数据库评估项目的实体框架.数据库设计得相当好,已经决定我们将使用Database-First方法.该应用程序将基于WinForms,但我想提前计划并考虑ASP.Net以及管理层可能会在某些时候请求,我想重用DAL.
现在,我了解Entity Framework为实体对象提供了几种方法:
我一直试图比较这三种方法,到目前为止我已经发现了这一点.
EntityObject T4模板是其中最丰富的.例如,它将来自实体模型的注释放在每个类和实体的每个属性之上的XMLDoc注释中,这在代码可维护性方面相当不错且有用.没有其他生成器支持这种开箱即用(虽然我知道可以修改T4模板,但它显然需要一些工作).另一方面,DbContext API更好一些.
EntityObject派生类型提供了一个事件,您可以在实体的属性更改时挂钩,这对实现业务逻辑很有用.
我知道POCO对此更自然,但每次模型更改时,T4生成器都会覆盖我的所有更改.当然,生成的POCO是部分类,但据我所知,不可能覆盖已经在部分类中定义的属性,所以我不确定如何在其中实现业务逻辑?
很多人似乎讨厌EntityObject派生类,更喜欢POCO方法,但似乎我失去了许多由EntityObjects开箱即用的有用功能,通过POCO路由.考虑到对POCO对象的普遍强烈偏好,我可能会误解某些东西,因此我的问题.
最后,哪个生成器最适合ASP.Net环境?我担心我的实体更改会被停止跟踪?自我跟踪实体在这种情况下是否更有用,或者它们是否仅具有Web服务的价值(我可能不会使用它)?
提前谢谢了.
如果要使用EF 4.1,则选项仅为DbContext Generator.所有其他生成器(POCO,EntityObject和STE)都用于ObejctContext API(EF 4.0).我描述生成器之间的差异在这里.
在你的情况下,EntityObject生成器可以用于WinForms,但是对于ASP.NET解决方案来说它会很麻烦,因为ASP.NET应用程序是分离的场景,所以POCO更好 - 你无论如何都必须处理ASP.NET中的更改跟踪.
这里描述了STE的目的,但它们在WinForm中并不是很有用,在WinForm中你可以直接使用附加实体,或者它需要在视图状态下的请求之间存储它们.
您想直接放入实体的任何业务逻辑必须在T4生成器中编码,否则每次生成后都会被覆盖.EntityObject您提到的基于生成器的每个功能也可以在POCO/DbContext生成器中实现.
| 归档时间: |
|
| 查看次数: |
2539 次 |
| 最近记录: |