代码生成器与ORM

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/历史-透视的-ORM-and.html

Answer 2

这确实取决于您的项目要求和开发过程。ORM 充满了很多奇才，给桌面带来了很多乐趣，但如果您只是购买一些独特的功能，您可能会发现所需的心理/物理基础令人失望。

您应该知道的第一件事是，有两种 ORM：将现有架构映射到应用程序逻辑（您管理架构）的 ORM 和将应用程序逻辑映射到架构（ORM 管理架构）的 ORM。您最好避免第一种，因为它们不会减轻您为每个环境执行/重复大量 DBA 工作的负担，即，您除了确保所有开发人员都在运行适当的模式之外，还必须确保他们'还运行适当的代码。第二种可以完全抽象您使用底层数据库的事实，因此它们允许您仅关注应用程序领域，这让开发人员感到高兴。

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

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

• 自动为您管理数据库架构
• 提供活动记录模式的就地实现
• 真正能够封装所有的业务逻辑

其他不错的糖：

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

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