实体框架——如何摆脱orm的限制,或者我应该避免它们



总之,像实体框架这样的orm提供了一个快速的解决方案,但有许多限制,什么时候应该避免使用它们(orm) ?

我想创建一个DMS系统的引擎,我想知道如何创建业务逻辑层。

我将讨论以下选项:

  • 使用实体框架,并将其作为业务提供给引擎的客户端。

    问题是缺少对属性和验证的控制,因为它是生成的代码。

  • 手动创建自己的业务层类,而不使用实体框架或任何ORM:

    问题是,这是一项艰巨的任务,有点像重新发明井。

  • 在实体框架上创建我自己的业务层类(使用它)

    问题似乎是通过创建具有相同名称的新类来重复代码,并且每个属性将覆盖由ORM生成的相反的一个。

我讨论问题的方式正确吗?

总之,在以下情况下应避免使用orm:

  • 您的程序将执行批量插入/更新/删除(例如插入-选择,以及以非唯一的东西为条件的更新/删除)。orm的设计并不是为了高效地执行这类批量操作;

  • 您正在使用高度自定义的数据类型或转换。orm通常不擅长处理blob,并且在如何告诉它们如何"映射"对象方面存在限制。

  • 在与SQL Server的通信中需要绝对最高的性能。orm可能会遇到N+1问题和其他查询效率低下的问题,总的来说,它们在你对对象的请求和SQL语句之间添加了一层(通常是反射的)转换,这会减慢你的速度。

在大多数基于应用程序的记录维护情况下,应该使用

orm,其中用户查看聚合结果和/或更新由简单数据类型组成的单个记录,每次一个。orm在使用Linq提供程序提供编译器检查查询方面比原始SQL有极大的优势;几乎所有流行的orm (Linq2SQL, EF, NHibernate, Azure)都有一个Linq查询接口,可以捕获很多"胖手指"和其他常见的错误,当你使用"魔法字符串"来形成sqlcommand时,你不会捕获这些错误。orm通常还提供数据库独立性。经典的NHibernate HBM映射是XML文件,可以根据需要交换出来,将存储库指向MSS、Oracle、SQLite、Postgres和其他rdbms。即使是"流畅的"映射,即代码文件中的类,如果架构正确,也可以被交换出来。EF也有类似的功能。

那么你是在问如何在不做"X"的情况下做"X"?ORM是一种抽象,和任何其他抽象一样,它有缺点,但不是你提到的那些。

  • 代码(EFv4)可由T4模板生成,T4模板为可修改代码
  • 生成的代码是部分类,可以与包含逻辑的部分组合在一起
  • 手动编写类是非常常见的情况-在实体框架中使用设计器更为罕见

免责声明:我在Mindscape工作,为。net构建LightSpeed ORM

因为你没有问一个具体的问题,而是问用ORM解决灵活性问题的方法,我想我应该从供应商的角度加入一些观点。它可能对你有用,也可能没有用,但可能会给你一些思考的食物:-)

在设计O/R映射器时,考虑我们所说的"逃生舱口"是很重要的。ORM将不可避免地推动一组默认行为,这是开发人员获得生产力的一种方式。

我们从LightSpeed中学到的教训之一是开发人员需要那些逃生舱口。例如,keith在这里指出orm不适用于批量操作——在大多数情况下这是正确的。我们为一些客户提供了这个场景,并在Remove()操作中添加了一个重载,该操作允许您传入一个查询,该查询删除所有匹配的记录。这就省去了将实体加载到内存中并删除它们的麻烦。倾听开发人员的痛处,并帮助他们快速解决这些问题,对于帮助构建可靠的解决方案非常重要。

所有orm都应该有效地批处理查询。话虽如此,我们惊讶地发现许多orm没有这样做。这很奇怪,因为批处理通常可以很容易地完成,并且可以将几个查询捆绑在一起并一次发送到数据库以节省往返时间。这是我们从第一天开始就为任何支持它的数据库做的事情。这只是对这条线中批量制作的一点的旁白。这些批量查询的质量是真正的挑战,坦率地说,有些orm生成了一些糟糕的SQL语句。

总的来说,你应该选择一个能让你立即获得生产力的ORM(几乎是演示软件风格的"看,我在30秒内查询了数据!"),但也要注意更大规模的解决方案,即需要逃生舱口和一些较少演示但非常有用的功能。

我希望这篇文章没有显得太过推销,但是我想提请大家注意,在选择任何产品时,都要考虑到产品背后的思考过程。如果你的理念与你需要的工作方式相匹配,那么你可能会比选择一个不匹配的更快乐。

如果你感兴趣,你可以了解我们的。net的光速ORM。

根据我的经验,当应用程序进行以下数据操作时,应该避免使用ORM:

1)批量删除:大多数ORM工具不会真正删除数据,他们会用垃圾收集ID (GC记录)标记它以保持数据库的一致性。最糟糕的是,ORM在将要删除的数据标记为已删除之前收集了所有数据。这意味着如果您想要删除1000000行,ORM将首先获取数据,将其加载到应用程序中,将其标记为GC,然后更新数据库;我相信这是一个巨大的资源。

2)批量插入和数据导入:大多数ORM工具将在业务类上创建业务层验证,如果你想要验证一条记录,这是很好的,但如果你要插入/导入数百甚至数百万条记录,这个过程可能需要几天时间。

3)报表生成:ORM工具很适合创建简单的列表报表或简单的表连接,比如在order-order_details场景中。但在大多数情况下,ORM只会减慢数据的检索速度,并会添加更多报表所需的连接。这将给DB引擎带来比通常使用SQL方法更多的工作

相关内容

最新更新