问代码生成器还是or？

EN

对我来说，这是不需要动脑筋的，你生成代码。

我将在这里稍微偏离主题，因为有一个更大的潜在谬误在起作用。谬误在于，这些ORM框架解决了对象/关系阻抗不匹配的问题。这种说法是明目张胆的谎言。

我发现解决对象/关系阻抗不匹配的最好方法是独占使用OOP并使用对象数据库，或者独占使用关系数据库的习惯用法而忽略OOP。

对我来说，抽象的“一切都是一个表”比抽象的“一切都是一个类”要强大得多。当您在数据库而不是对象模型中编码时，它需要更少的代码，更少的智力工作，并导致更快的代码。

对我来说，这是显而易见的。如果你的应用程序是数据驱动的，那么你的代码肯定也应该是数据驱动的？然而，要说这是非常有争议的。

这里的中心问题是，当OOP与数据库结合使用时，它会成为一个非常容易泄漏的抽象概念。当您看到代码在数据库中生成的流量时，看起来完全合理的代码在编写为OOP的习惯用法时看起来完全疯狂。当这种混乱成为性能问题时，OOP是第一个受害者。

真的没有办法解决这个问题。数据库使用数据集。OOP主要关注类的实例。试图让这两个人结婚总是会以离婚告终。

因此，为了回答你的问题，我认为你应该生成你的类，并尝试让它们尽可能地映射底层数据库结构。

也许有争议的是，我一直觉得使用ADO.NET管道的代码生成器从根本上解决了错误的问题。

在某种程度上，希望在学习了连接字符串、SqlCommands、DataAdapters和所有这些之后不久，我们会注意到：

1. 这样的代码很难看
2. 写
3. 很无聊很容易遗漏一些东西如果你是手工做的
4. 每次你想要访问数据库的时候都要重复<

>G29

所以，要解决的问题是“如何多次快速地做同样的事情”？

我说不是。

使用代码生成器使此过程更快仍然意味着您的业务类(或数据访问层，如果您将其与业务逻辑分离)上仍然有大量的代码。

然后，如果你想做一些一般性的事情(例如，跟踪存储过程的使用)，如果你的代码生成器还没有你想要的特性，你最终不得不定制它。即使它发生了，你仍然必须一直重新生成所有的东西。

我喜欢做一次事情，而不是很多次，不管我能做多快。

因此，我推出了自己的数据访问类，它知道如何添加参数、设置和关闭连接、管理事务和其他很酷的东西。它只需编写一次，从需要完成某些数据库内容的Business object调用它的方法只需一行代码。

当我需要使应用程序支持多线程数据库访问时，只需要更改数据访问类，所有的业务类都只做它们已经做过的事情。

没有正确的答案，这完全取决于你的项目。正如Simon指出的，如果您的应用程序都是数据驱动的，那么根据领域的大小和复杂性使用非oop范例可能是有意义的。我使用事务脚本模式成功地构建了一个系统，该模式在系统中传递XML消息。

然而，随着应用程序在规模和复杂性上的增长(5或6个web、几个web服务、大量的COM+组件、遗留和.net代码、带有800+表和过程的8+数据库)，这个系统在五六年后开始崩溃。没有人知道任何东西是什么，复制正在泛滥。

除了OOP之外，还有其他方法可以减轻维护性；但是，如果您有一个非常复杂的域，那么使用富领域模型是理想的IMHO，因为它允许业务规则在良好的封装组件中表示。

要回答您的问题，请尽可能避免代码生成器。代码生成器是导致灾难的秘诀，但如果您使用代码生成，请不要修改生成的代码。另外，一定要有一个很好的流程，开发人员可以很容易地获得新生成的代码。

我推荐使用以下两种方法: ORM或hand轻量级DAL。我目前正在将一个项目从我的手工滚动DAL过渡到nHibernate，并且取得了很多成功；然而，我喜欢使用这两个选项中的任何一个。此外，如果您正确地分离了您的关注点(从业务层到表示层的数据访问)，您可以拥有一个可以与Dao (数据访问对象)通信的服务层，该对象对于一个对象是ORM，而对于另一个对象是手动滚动的)。我喜欢这种灵活性，因为它允许将最好的工具应用到工作中。

与手动滚动的DAL相比，我更喜欢nHibernate，因为虽然我的DAL确实抽象了大部分ADO.Net代码，但您仍然需要编写将数据读取器带到对象或对象并创建参数的代码。