Question

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

谢谢！

Answer 1

我进行了网络编程，其新版语言缺乏正确的数据处理（这导致了对ORM的感知需求），同时我构建了我的全部代码生成器。从未回头。

我永远不会考虑ORM的一个原因是因为我实际上知道数据库是如何工作的，非常感谢你。我没有尝试让它看起来像我没有使用关系数据库，我希望有一些东西可以让我尽可能少地使用数据库的力量 - 而且永远不会是ORM，因为那是不是他们的意思。

根据我的经验，一个好的基于字典的生成器是最真实的DRY编程（不要重复自己），它可以让我摆脱使用数据库的挑剔，让我专注于重要的事情，在稳固的表设计之上编写好的逻辑逻辑。

编辑：还有两点：

1）如果没有别的话，去非ORM路线孤独，因为ORM非常愤怒，很难找到那些从不需要它并且看不到的人关键点。但是，让你的技术判断指导你。

2）几年前，我写了一篇博客文章“为什么我不使用ORM”，我不会链接到它，因为它太煽动了。过了一段时间后，我再次尝试捕捉为什么有可能客观地看待ORM并且看不到任何价值，而不是煽动性，并且链接是：http://database-programmer.blogspot.com/2010/12/historical-perspective-of-orm-and.html

Answer 2

取决于;你喜欢用数据库做无用的繁忙工作，还是想更好地生成？

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

真的，这是决定你想花时间的问题。如果你看到在数据层工作的价值，由于一些原因，你可以证明，当权衡LLBLGen之类的东西时，那就去做吧。但对我来说，我没有。

当然，我同意你的意见，不得不经常改变ORM并不理想。因此，我建议您花一点时间（可能是几周）确定哪一个最适合您喜欢的风格，以及您构建项目的方式，然后去实现它。无论如何，大多数主要方式都得到了很好的支持，所以你不能选择其中一种并将其标准化。

Answer 3

支持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;
}

Answer 4

对于简单的CRUD，如果对象代表表格代码生成器，则可以直接达到目标。如果

，ORM变得越来越有趣

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

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

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

Answer 5

这确实取决于您的项目要求和开发过程。 ORM包含了很多高手，给桌子带来了很大的乐趣，但是如果你只是购买一些不同的功能，你可能会发现所需的心理/身体上的烦恼令人失望。

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

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

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

自动管理数据库架构
提供Active record pattern
真的能够封装所有业务逻辑

其他好糖：

自动管理数据迁移（如果您希望频繁更改本体而不是更改）
支持生成/导入灯具

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

代码生成器与ORM

5 个答案: