在我的项目中不使用NHibernate是不是很愚蠢？

Question

我正在使用.NET Web应用程序,该应用程序使用大约20到30个表的SQL Server数据库.大多数表将作为类包含在.NET解决方案中.我编写了自己的数据访问层来读取对象,并将它们写入数据库.整个过程只包含几个类,很少的代码行使用泛型和反射来找出要使用的SQL和参数.现在,这样的事情可以通过使用NHibernate(或similair框架)完成,而一些同事声称我不使用它是愚蠢的.我不使用它的主要理由是我希望能够最大限度地控制我的应用程序,确切地知道所有事情的作用以及一切是如何工作的,即使这花费了我更多的开发时间.我也不喜欢我必须将我的数据库映射到XML文件中(我自己的解决方案让我将它映射到实体类文件中).

所以,我想听到你的意思是,在这种情况下不使用NHibernate真的很蠢吗？我真的无知或使用我自己的解决方案是不是一个奇怪的想法？

Answer 1

我认为现在没有任何理由推出自己的持久性框架,因为那里有很多好的选择.你不必使用NHibernate(虽然它是一个不错的选择),但我会认真考虑使用经过良好测试和在业界建立的东西,因为它往往会表现得更好,并且你自己写的东西更少.

Answer 2

编写自己的类而不是使用NHibernate 可能是愚蠢的,但是如果你已经编写了它们,继续使用自己的类就不那么愚蠢了.也许.

Answer 3

你有几种可能性比你重新发明轮子更好.让我说出两个最有可能的选择:

1. 使用实体框架为您的DAL + DAO.这将使您的课程(您已经编写过的)过时,因为EF将创建自己的课程,您将获得最新的语言功能和技术.

2. 使用Fluent NHibernate,因此您不必使用XML映射.这样,您将保留您编写的业务层对象类,并避免繁琐的NHibernation XML文件.这都是C#.

你的思维方式很好.你想控制.没关系.但是现在使用你自己的DAL有点愚蠢,因为你基本上都在重新发明轮子,而且你还没有测试过/需要花费大量时间来开发+测试和调试的错误代码.

如果我是你,我会选择#2选项,因为我已经完成了选项#1,我知道我必须定制很多东西才能使EF工作正常.EF将准备好V2.

Answer 4

我不会称你为愚蠢,因为我过去做过同样的事情.然后我开始使用NHibernate,并想知道我为什么要自己动手.这很好,试一试.

Answer 5

人们倾向于使用已经编写的框架,因为它们已经编写(并经过测试).

但是推销你自己是有价值的.只有您和您的同事才能对您的域名做出假设.像NHibernate这样的通用框架不能做出很多假设,因为这不会使它非常普遍.

当您自己动手时,可以将这些假设烘焙到您的框架中,以制作更简化的自然API.也就是说,如果你重新开始我会建议采用现有的框架并将其包装起来以更好地满足您的需求.但既然你已经拥有了它并且它适合你,我不确定我是否会建议将其换成其他东西.