我正在开发一个.NET Web应用程序，该应用程序使用的SQL Server数据库大约有20到30个表。 大多数表将作为类包含在.NET解决方案中。 我编写了自己的数据访问层来读取对象，并将它们写入数据库。 整个过程只包含几个类，很少的代码行使用泛型和反射来找出要使用的SQL和参数。 现在，这样的事情可以通过使用NHibernate（或similair框架）完成，而一些同事声称我不使用它是愚蠢的。 我不使用它的主要理由是我希望能够最大程度地控制我的应用程序，确切地知道所有事情的作用以及一切是如何工作的，即使这花费了我更多的开发时间。 我也不喜欢我必须在XML文件中映射我的数据库（我自己的解决方案让我将它映射到实体类文件中）。
所以，我想听到的是，在这种情况下不使用NHibernate真的很蠢吗？ 我真的无知，或者使用我自己的解决方案是不是一个奇怪的想法？
答案 0 :(得分：24)
我认为现在没有任何理由推出自己的持久性框架，因为那里有很多好的选择。你不必使用NHibernate（虽然它是一个不错的选择），但我会认真考虑使用经过良好测试并在业界建立的东西，因为它会更好地表现并且你自己编写的东西更少。< / p>
答案 1 :(得分：12)
编写自己的类而不是使用NHibernate可能 是愚蠢的，但是如果您已经编写了它们，那么继续使用自己的类是少愚蠢。也许。
答案 2 :(得分：6)
你有几种可能性比重新发明轮子更好。让我说出两个最有可能的选择：
为您的DAL + DAO使用实体框架。这将使您的课程（您已经编写过）过时，因为EF将创建自己的课程，您将获得最新的语言功能和技术。
使用 Fluent NHibernate ，这样您就不必使用XML映射。这样，您将保留您编写的业务层对象类，并避免繁琐的NHibernation XML文件。这都是C＃。
你的思维方式很好。你想控制。没关系。但是现在使用你自己的DAL有点愚蠢，因为你基本上都在重新发明轮子，而且你还没有测试/错误代码，这需要花费大量时间来开发+测试+调试。
如果我是你，我会选择＃2选项，因为我已经完成了选项＃1，我知道我必须自定义很多东西才能使EF工作正常。 EF将准备好V2。
答案 3 :(得分：6)
我不会称你为愚蠢，因为我过去做过同样的事情。然后我开始使用NHibernate，并想知道我为什么要自己动手。这很好，试一试。
答案 4 :(得分：5)
人们倾向于使用已经编写的框架，因为它们已经被编写（并经过测试）。
但是推出自己的优点是值得的。只有您和您的同事才能对您的域名做出假设。像NHibernate这样的通用框架不能做出很多假设，因为这不会使它非常普遍。
当你自己动手时，你可以将这些假设烘焙到你的框架中，以制作更加流线型的自然API。也就是说，如果你重新开始我会建议采用现有的框架并将其包装起来以更好地满足您的需求。但既然你已经拥有了一些适合自己的东西，我不确定是否会建议将其换成别的东西。
答案 5 :(得分：3)
这取决于他们所说的“愚蠢”。
如果说“愚蠢”，他们的意思是你不应该首先编写你的持久层，他们可能是对的，但那是在溢出的牛奶上哭泣。
如果“愚蠢”，他们的意思是你应该重写所有现有的代码以使用另一个框架（如NHibernate），当它已经与你合作时，它们可能是错的（尽管NHibernate中的错误有些说法） vs可能是你的错误＃。
如果“愚蠢”，他们的意思是整个团队都知道NHibernate很冷，而且它已经在你的其余代码中使用了，所以通过使用你的框架你会让团队变得更难，他们是绝对正确的，在更多代码被锁定到框架之前，你应该尽快重构NHibernate中的代码。
如果“愚蠢”，他们的意思是没有人真正了解NHibernate，他们只是喜欢它，然后......没有人赢。他们很挑剔，你实施了一个你没有必要的框架......让我们称之为平局。
所有这些都说，每个人都应该写一个或三个持久性框架。那些可能不应该最终出现在船上，但这是一个很好的练习。你犯的唯一错误就是将团队必须维护的代码绑在你的良好运动中。
答案 6 :(得分：1)
有许多优秀的持久性工具经过充分测试并具有经过验证的性能（NHibernate，Linq to entities，LLBL Gen Pro）。如果您的需求与现有的常规持久性框架非常不同，那么我将自己推出。但是，如果可能的话，我想利用现有工具的测试和优化。
话虽如此，如果我想拥有构建自己的ORM工具的经验并且愿意忍受缺点（不像经过多年的工具那样经过充分测试或优化，加快上市速度。）
答案 7 :(得分：1)
制定自己的解决方案，特别是当它看似工作正常并且如您所说的那样简单时，既不是无知也不是奇怪。在很多情况下，这样做比在nHibernate这样的单独项目中添加依赖项更好。
那就是说，当然也有很多情况完全相反。 ：）
这实际上取决于您的项目和团队。如果您正在开发最终将得到其他人支持的企业应用程序，那么坚持行业标准可能是一个好主意，即使它意味着预先做更多工作。
答案 8 :(得分：1)
这里的所有答案都很棒，但我很惊讶没有人提到Castle ActiveRecord，这听起来与你的框架非常相似，并且真正简化了NHibernate的界面。这是让Ruby on Rails如此受欢迎的模式之一！
几年前，Ayende Rahien（主要NH开发人员之一）在Oredev上发表了关于ActiveRecord的精彩演讲，我强烈推荐：http://www.viddler.com/explore/oredev/videos/89
答案 9 :(得分：0)
我认为这是一个控制平衡的问题。你说你想要控制而你不想要映射。如果这种控制的代价是开发和维护成本增加，并且生成工作代码需要更长的时间，那么这就是一个问题。
我个人看不到滚动框架的问题，只要它简化了重复性任务，并且由于更少的解释空间，使开发更高效，代码更稳定。我们已经推出了自己的框架，其中包括持久性/数据访问实现。但是，我们这样做的原因是具体的。在这种情况下，它是在一个DDD环境中工作，这个环境比Evans所描述的更接近于大多数现成产品提供的环境。
我认为不同之处在于，我们了解到有前期成本，并且最终会通过节省开发时间来平衡自己。当然，如果您正在编写手动必须管理连接，地图数据等的代码，那么您可能会走错路。至少，您可以使用Enterprise Library之类的东西来帮助您管理连接和命令构建的繁琐工作。但是，我也认为，如果你没有重用 - 没有什么是“框架”类型的实现，你可以抽象并应用于其他项目，那么你创建一个维护噩梦和时间汇，你将成为唯一的所有者的。
答案 10 :(得分：0)
我们还使用了自己的数据访问层和实体类。我们还有一个代码生成器，用于为我们生成所有这些类。但现在我们正在使用实体框架，我们更高兴。
简单建议：开始学习nHibernate或您喜欢的任何内容，并在下一个项目中开始使用它。
答案 11 :(得分：0)
实体空间 - http://www.entityspaces.net/Portal/Default.aspx
也是一个很好的工具。
答案 12 :(得分：0)
我最终使用Fluent NHibernate完成这项工作。 我的所有实体类都是使用ActiveRecordGenerator（http://code.google.com/p/active-record-gen/）
生成的