代码生成器vs ORM

我写了一个代码生成器，它为给定的SQL Server/CE数据库生成POCO和存储库。没有什么奇特的，只有简单的使用经典的ADO.Net的CRUD程序。我的问题是，为什么我应该在自定义代码生成器上使用像L2S/EF4这样的ORM？微软每两到三年发布一些新的数据访问框架/技术，我知道有不少开发者不能总是接触到最新的技术，但他们都知道经典的ADO.Net，如何修改现有代码以及如何开发新功能。 ORM工具是否带来了现在必须的东西，或者我可以坚持使用经典的ADO.Net？代码生成器vs ORM

谢谢！

来源

2011-01-24 šljaker

很好的问题，在我看来。 – Earlz 2011-01-24 23:17:55

如果说别人需要接管你的项目，赔率是他可能知道EF4或NHibernate的 - 但最有可能不是你家种的解决方案...如果你独奏程序员：没有问题的。如果你是公司团队的一员：巨大的问题。 – 2011-01-25 05:40:27

它确实取决于您的项目需求和您的开发过程。 ORM充斥着许多智者，给桌子带来了许多乐趣，但如果你只是购买一些独特的功能，你可能会发现所需的精神/体力上的不足，令人失望。

您应该知道的第一件事是有两种ORM：将现有模式映射到应用程序逻辑（管理模式）的映射以及将应用程序逻辑映射到模式（ORM管理模式）的映射。你最好避免使用第一种方法，因为它们不会减轻你为每个环境做/重复相当多的DBA工作，即你必须确保所有的开发人员都运行适当的模式，除了确保他们'还要运行适当的代码。第二种类型完全可以抽象出使用底层数据库的事实，因此它们可以让您专注于应用程序域，这使开发人员感到高兴。

没有DBA，没有更多针对无法管理的远程数据库实例的本地开发工作，没有更多的交叉RDBMS细微差别，没有更多的存储过程，没有更多的硬编码查询查询，没有更复杂的SQL迁移查询。

所以，最好你的ORM应该：

自动管理数据库架构为您
提供就地实施Active record pattern
真的能封装所有的业务逻辑

其他漂亮的糖：

自动管理数据迁移（如果你希望，而不是没有变化频繁本体的变化）
支持像@Noon所说的产生/进口灯具

请记住，你可以用一个ORM启动任何项目，但是如果没有它，你现在就无法开始每一个项目。理想情况下，ORM非常适合您希望开发人员完全控制的项目，或者需要他们运行私有的本地数据库实例。无论哪种方式，这是从屁股后退方式的一个巨大飞跃：向DBA发出请求，喝咖啡直到DB被更新，希望它在一周内发生。

来源

2011-01-25 00:40:45

取决于;你喜欢在数据库中做一些无用的繁忙工作吗？或者你更喜欢把它全部生成？

说真的，对我来说，绝对没有问题。每个知道的项目都应该以ORM开始，对我而言，LLBLGen是最好的。虽然这不是免费的。但是它在开发数据层方面节省了很多时间，并提供了一个很好的结构。

真的，这是一个决定你想如何花时间的问题。如果您看到在数据层中工作的价值，那么由于一系列可以证明的理由，比如在对LLBLGen等进行权衡时，应该这样做。但对我而言，我不知道。

当然，我同意你的观点，不断地改变ORM的方式并不理想。所以我建议你花一点时间（也许几个星期）来决定哪一种最适合你喜欢发展的风格，以及你组织项目的方式，然后去做。无论如何，现在大多数主要方式都得到了很好的支持，所以你不能选择其中的一种并将其标准化。

来源

2011-01-24 23:15:03

谢谢你的回答！关于“无用的数据库繁忙工作”，我可以尽可能快地使用一些ORM来设置DAL。我可以花一个月寻找一个完美的ORM并选择NHibernate，但几个月后，MS将会发布EF5，这将是下一个重大事件（或者在6个月之后），并且所有参与当前项目的开发人员都将拥有花一些时间来学习这个新事物，以便成功重构现有的代码。 – 2011-01-24 23:28:52

@šljaker。第一部分是作为一个笑话。但是，严肃地说，持续维护需要很简单。我发现LLBLGen比起那些产生了一堆SP（需要修改或重新生成等）的东西更容易。我听到你对新技术的看法。这就是为什么你需要坐下来找到一个现在很好的，并有一个你可以同意的好路径。当然，你不能让你的团队不断变化。只有有强烈的理由才能改变。 – 2011-01-24 23:31:48

对于简单的CRUD，如果对象表示一个表代码生成器可以直接实现您的目标。奥姆斯变得越来越有趣，如果

你有复杂的对象关系和需要遍历对象引用，
需要一些缓存机制，
需要处理的并行读/写，
需要一些版本表中的行，
必须处理继承，
...

简而言之：如果您需要更多只是表和对象之间的简单映射，那么ORM可能很有用。因此您需要查看ORM的功能列表并询问您是否需要它。

在代码生成器和完整的ORM之间还有一种替代方法：数据映射器（如MyBatis，以前称为iBatis）。

来源

2011-01-24 23:40:47

有利于ORM的一点是编译时检查。我将以实体框架为例，因为这就是我用作ORM的原因。

如果您需要在开发过程中进行数据库模式更改（删除列，表等），则需要从数据库更新模型，然后进行编译。到处引用该列或表的地方现在显示为编译时错误，从而很容易发现错误，这些错误很可能只在标准ado.net的运行时才会发现。

另一件需要考虑的问题是临时查询 - 如果您想从表中仅拉回几列数据，该怎么办？使用生成的代码，你需要添加一个新的查询，类来填充数据等等。使用ORM，你可以做这样的事情，为你生成一个匿名类，所以你不必经过繁忙的工作自己创造一个。

本质上，ORM将处理家庭解决方案通常不会处理的所有边缘情况。

var q = from c in ctx.contact 
     where c.contactId < 4 
     select c.firstName, c.lastName; 


foreach(var temp in q){ 
    string fullname = temp.firstName + " " + temp.LastName; 
}

来源

2011-01-24 23:43:16 Neil

šljaker询问ORM与生成的代码不是针对即席查询 – 2011-01-25 00:12:04

我开始使用网络编程，在我建立我的全能型代码生成器的同时，它的新语言缺乏正确的数据处理（这导致了对ORM的需求）。从未回头。

我永远不会考虑ORM的一个原因是我真的知道数据库是如何工作的，非常感谢你。我不知道的东西，试图使它像我不使用关系型数据库的样子，我想要的东西，让我的数据库的权力用尽可能少的工作地 - 这绝不会是一个ORM，因为这是不是他们的意思。

根据我的经验，一个很好的基于字典的生成器是最真实的DRY编程（不要重复自己），它可以使我摆脱与DB一起工作的挑剔，并让我专注于重要的事情，在坚实的桌子设计之上得到良好的biz逻辑。

编辑：两分：

1）去非ORM的路线是，如果不出意外，寂寞，因为ORM那么多，很难找到人的愤怒谁从来不需要它，也看不到这一点。但让你的技术判断指导你。

2）几年前，我写了一篇博客文章，“我为什么不使用ORM”，我不会链接到，因为它太炎症。过了一段时间我试图再次捕捉到它为什么可以在ORM看起来客观，看不出有什么价值，但是不发炎的感觉，而且链接是：http://database-programmer.blogspot.com/2010/12/historical-perspective-of-orm-and.html

来源

2011-01-25 00:49:41

代码生成器vs ORM

回答

相关问题