我应该坚持实体框架吗？

Question

我在我的新网络应用程序中采用了EF(开箱即用).

这个应用程序确实涉及对db活动的一些操作,并涉及大约30个或更多表.

我的观点是,这不是一个简单的学校项目,EF通常适合大多数需求.

随着我开发此应用程序的进一步发展,我发现EF非常有限或禁止正确/良好的数据库设计(特别是在术语性能方面)

1)包括

我在查询部分遇到Include功能.许多数据丢失是由于缺少包含设置.

我投入的东西越多,我就越担心简单的数据检索会获得比我在某些功能中所需要的更多的东西.

2)验证

我采用流利验证了这方面的需要,因为我更喜欢访问者模式,在需要的地方过来的数据代码本身没有直接的代码更改.

但是当我进行子类化时,我遇到了更多的挑战,我需要锻炼验证能够尊重OOP简单的东西.我管理它,虽然更复杂和某些我真的不喜欢它的实现.我相信这个子类验证问题也发生在DataAnnotation中.

3)交易

现在,我需要合并适当的数据库事务处理控制,我发现EF缺少这个,如果我错了,请纠正我.

我曾经使用Enterprise组件(很久以前的.NET中的COM +),我在EF中找不到正确的(或缺少它)事务实现.

我还在努力......

结论)

我开始意识到EF在我的编码中唯一帮助我的是数据/实体代码生成,这是许多其他工具/框架的共同特征.

我想放弃这个EF,切换回前EF时代的方法,采用存储过程,仍然是代码生成的表类(但不是EF或DBML).

我可以不用SQL LINQ,因为我在过去的性能问题上遇到了很多挑战.

我喜欢你的观点,我应该留下并坚持EF,无论出于什么原因,我的简单思维能够感知到,除了这个ORM,它几乎没有现实的工作.

Answer 1

你看过Dapper了吗？Dapper是一种超快速的微型ORM.它是由Stackoverflow人员(Sam Saffron)开发的,他们在这个网站上广泛使用它,因为你提到的原因 - 性能和速度.链接在这里:

https://github.com/StackExchange/dapper-dot-net.

我们放弃了EF,我们只使用Dapper.结合其他社区开发的Dapper扩展,如Dapper.SimpleCRUD和Dapper.SimpleCRUD.ModelGenerator,我们可以从数据库中快速生成POCO,同时保留Dapper优于EF的所有优势.总的来说,您将编写更多代码,但Dapper的速度几乎相当于使用ADO.NET的SqlDataReader.这是SimpleCRUD的链接:

https://github.com/ericdc1/Dapper.SimpleCRUD/