代码生成器与ORM

Question

我写了一个代码生成器，它为给定的SQL Server/CE数据库生成POCOs和存储库。没有什么花哨的东西，只有使用经典ADO.Net的简单CRUD过程。我的问题是，为什么我应该使用像L2S/EF4这样的ORM而不是自定义代码生成器？每隔2到3年，微软就会发布一些新的数据访问框架/技术，我认识很多开发人员，他们并不总是接触最新的技术，但他们中的每个人都知道经典的ADO.Net，如何修改现有代码以及如何开发新的功能。是ORM工具带来了现在必须的东西，还是我可以坚持使用经典的ADO.Net？

谢谢!

Answer 1

它确实取决于您的项目需求和开发过程。ORM中充斥着大量的天才，并带来了很多的joy，但如果你只是购买几个不同的功能，你可能会发现所需的精神/身体上的crud令人失望。

首先，您应该知道有两种ORM :将现有模式映射到应用程序逻辑(您管理模式)的ORM和将应用程序逻辑映射到模式(ORM管理模式)的ORM。您最好避免第一种类型，因为它们不会减轻您为每个环境做/重复大量DBA工作的负担，也就是说，您必须确保所有开发人员都在运行适当的模式，此外还必须确保他们也在运行适当的代码。第二种可以完全抽象您使用底层数据库的事实，因此它们允许您只关注应用程序域，这让开发人员感到高兴。

没有DBA，不再有针对不可管理的远程数据库实例的本地开发工作，不再有跨RDBMS的细微差别，不再有存储过程，不再有具有硬编码引用的查询，不再有更复杂的SQL迁移查询。

因此，理想情况下，您的ORM应该：

• 自动为您管理DB模式
• 提供就地实现的

能够封装所有业务逻辑

其他可口的糖：

• Automatically管理数据迁移(如果您期望频繁的本体更改，而不是没有用于生成/导入装置的changes)
• Support

请记住，你可以像@Noon说的那样使用ORM启动任何项目，但现在你不能在没有ORM的情况下启动每个项目。理想情况下，ORM非常适合您希望开发人员完全控制或需要他们运行私有的本地DB实例的项目。无论哪种方式，这都是一个巨大的飞跃:向DBA提出请求，喝咖啡，直到数据库更新，希望这在一周内发生。

Answer 2

我去了web编程，它的新语言缺乏适当的数据处理(这导致了对ORM的感知需求)，同时我构建了我的be-end-all代码生成器。从来没有回头看过。

我永远不会考虑ORM的一个原因是，我实际上知道数据库是如何工作的，非常好，谢谢。我不想让它看起来不像是在使用关系数据库，我想要的是用尽可能少的工作获得数据库的强大功能的东西--这永远不会是ORM，因为这不是它们的用途。

根据我的经验，一个好的基于字典的生成器是最真实的D-R-Y编程(不要重复自己)，它可以将我从使用DB的琐碎工作中解放出来，让我专注于重要的事情，在可靠的表设计之上编写良好的业务逻辑。

编辑：另外两点：

1)走非ORM路线是孤独的，因为ORM是如此流行，很难找到从来不需要它的人，也看不到它的意义。但是让你的技术判断来指引你。

2)几年前，我写了一篇博客文章“为什么我不使用ORM"，我不会链接到它，因为它太激动人心了。过了一段时间后，我再次尝试理解为什么可以客观地看待ORM，却看不到任何价值，而不会引起争议，这个链接是：http://database-programmer.blogspot.com/2010/12/historical-perspective-of-orm-and.html

Answer 3

取决于；您是喜欢在数据库中做无用的工作，还是更喜欢将其全部生成？

说真的，对我来说，这是绝对没有问题的。每个已知的项目都应该从对象关系模型开始，对我来说，LLBLGen是最好的。不过，这不是免费的。但是它节省了开发数据层的时间，并且提供了一个很好的结构。

实际上，这是一个决定你想如何消磨时间的问题。如果您看到了在数据层工作的价值，因为一些您可以证明的理由，当与LLBLGen之类的东西进行权衡时，那么就去做吧。但对我来说，我没有。

当然，我同意你的观点，必须不断地改变ORM是不理想的。因此，我建议您花一点时间(也许几周)来确定哪种开发方式最适合您喜欢的开发风格，以及您构建项目的方式，然后去尝试它。如今，大多数主要方法都得到了很好的支持，所以选择其中一种方法并将其标准化是没有错的。