代码生成器与 ORM

发布于 2024-10-14 05:44:08 字数 276 浏览 0 评论 0原文

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

谢谢你！

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

一个人练习一个人 2024-10-21 05:44:08

我开始进行 Web 编程，其较新的语言缺乏适当的数据处理（这导致人们认为需要 ORM），同时我构建了我的万能代码生成器。从未回头。

我永远不会考虑 ORM 的原因之一是因为我实际上知道数据库是如何工作的，非常感谢。我不想让它看起来像我没有使用关系数据库，我想要一些东西让我以尽可能少的工作获得数据库的力量——而这永远不会是一个 ORM，因为那是不是他们的目的。

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

编辑：还有两点：

1）走非 ORM 路线，如果没有别的原因的话，孤独，因为 ORM 如此流行，很难找到合适的方法。那些从来不需要它并且看不到意义的人。但让您的技术判断来指导您。

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

回复收藏 0 原文

奢欲 2024-10-21 05:44:08

视情况而定；您喜欢对数据库进行无用的忙碌工作，还是更喜欢将其全部生成？

但说实话，对我来说，这是绝对没有问题的。每个已知的项目都应该从 ORM 开始，对我来说，LLBLGen 是最好的。但它不是免费的。但它节省了开发数据层的大量时间，并提供了一个很好的使用结构。

事实上，问题在于你想如何度过时间。如果您看到在数据层工作的价值，并且在与 LLBLGen 之类的东西进行权衡时，由于一系列您可以证明的原因，那么就去做吧。但对我来说，我不这样做。

当然，我同意你的观点，不断地改变 ORM 并不理想。因此，我建议您花一些时间（也许几周）来确定哪一种最适合您喜欢的开发风格以及您构建项目的方式，然后继续使用。无论如何，现在大多数主要方式都得到了很好的支持，因此您选择其中一种并将其标准化是无可厚非的。

回复收藏 0 原文

栖迟 2024-10-21 05:44:08

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

One point in favor of an ORM is compile time checking. I'll use the entity framework as an example, since that's what I use as an ORM.

If you need to make a database schema change during development (remove a column, table, etc.), you update your model from the database and then compile. Everywhere that column or table was referenced now shows up as a compile time error, making it easy to catch bugs that would likely only be noticed at runtime with standard ado.net.

Another thing to think about is ad-hoc queries - what if you want to pull back just a few columns of data from a table? With generated code, you need to add a new query, class to fill with data, etc. With an ORM, you can do something like this, where an anonymous class is generated for you so you don't have to go through the busywork of creating one yourself.

Essentially, an ORM will handle all the edge cases that a home grown solution generally doesn't.

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

回复收藏 0 原文

蓝礼 2024-10-21 05:44:08

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

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

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

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

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

其他不错的好处：

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

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