关于何时使用其中一种工具与另一种相反的共识是什么?我发现Subsonic在快速完成任务方面非常有用,但在大型项目中,它往往无法扩展,并且它将您的域模型与数据库模型联系起来。这就是Nhibernate的用武之地,因为它为您提供了与您的数据库模型无关的轻量级POCO,但设置时间要长得多。
答案 0 :(得分:83)
我经常被问到这个问题,这真的归结为你想要多少提琴。我无法告诉你Chris Cyvas对RE SubSonic扩展的评论是多么具有破坏性 - 从那时起我就一直在回应这些:(。
这笔交易是 - 贯穿始终,SubSonic非常精准。在项目增长方面 - 您使用的任何工具都需要您的关注。甚至NHibernate。
我写了一篇关于如何使用DI的Repository模式的帖子(就像你使用NHIb或任何工具一样)和SubSonic 2.1:
http://blog.wekeroad.com/blog/subsonic-writing-decoupled-testable-code-with-subsonic-2-1/
我还写了一篇关于SubSOnic表现的文章:
http://blog.wekeroad.com/blog/subsonic-scaling/
希望这有帮助。
答案 1 :(得分:45)
如果您的项目使用ActiveRecord视图,数据库是您的模型,我建议使用SubSonic。你会得到每桌一个班级,一切都神奇地起作用。你当然可以调整和覆盖一些东西,但如果你(或你的项目)从根本上不同意每表类的方法,我会看看NHibernate,因为它从更复杂(但更灵活)的映射你的方法开始域模型到您的数据库。
如果您正在使用一个相对简单的数据库,这个数据库在您的控制之下(例如,您可以更改列而不将8个表单发送到数据库部门监督审核委员会),我建议从SubSonic开始,如果SubSonic转移到NHibernate不符合你的需求。
答案 2 :(得分:31)
它的价值......自从提出这个问题以来,我有机会更加使用这两种技术。如果你选择的这些技术很少,我必须坚持下去。当然NHibernate允许您的业务实体与您的数据库结构稍微耦合,但我仍然发现在很多情况下您仍然需要屈服于数据库的意愿。
在我看来,从数据库模型中完全分离域模型的唯一真正方法是编写自己的DTOS(基本上用于传递数据的POCO),然后将它们映射回您选择的ORM在您的数据层中。但在大多数情况下,这种方法比我的价值更麻烦。
答案 3 :(得分:13)
稍微偏离主题,但以类似的方式。您是否查看了Castle ActiveRecord它是在NHibernate之上编写的,并且无需花时间从代码到数据库创建XML映射。与NHibernate一样,您可以根据需要构建域对象,然后从此结构生成数据库模式。
使用ActiveWriter,一个贡献工具,您可以轻松地从数据库映射到域对象。
答案 4 :(得分:9)
你可以考虑看一下Fluent NHibernate;它使管理NHibernate变得轻而易举。不确定转换现有模式有多困难,但是如果你正在构建一个新的应用程序,那么定义域模型并在几乎任何你能想到的数据库服务器中生成数据库都是很好的。通过阅读其他评论,我认为Fluent NHibernate使NHibernate与SubSonic相提并论,便于配置。
答案 5 :(得分:7)
我不能给出一个很好的比较,因为我还没有在项目中实际使用过NHibernate,但是我已经使用过SubSonic并对它非常满意。到目前为止,我在使用它时没有遇到任何重大障碍。
查看SubSonic的创建者之一Rob Conery的this post。他谈到了如何将SubSonic代码与应用程序的其余部分分离。他甚至提到这样一个事实,即这个架构可以让你以后将SubSonic换成其他数据访问层,如NHibernate或LINQ to SQL。
我知道我实际上没有回答你的问题,但我希望这仍有帮助。
答案 6 :(得分:7)
我wrote a blog post最近关于其中包含Subsonic的.NET ORM和ActiveRecord。根据我的经验,它取决于项目正在做什么,如果你来自SQL背景,那么Subsonic工作得更好,但是NHibernate有更多的ontop。 ActiveRecord适用于较小的项目,我不相信它对于大型项目来说比坚持使用NHibernate更快。
答案 7 :(得分:5)
我已对两者进行了评估,并且我认为在不了解您的目标的情况下推荐一个而不是另一个是不公平的。在你的问题中,你很好地说明了这些差异,我认为这需要成为你的决定因素。就个人而言,我已经使用了两者,并将继续使用两者,具体取决于项目。
答案 8 :(得分:4)
再次稍微偏离主题,但我将第二个Castle ActiveRecord - 而不是使用数据库作为您的模型(Subsonic方法)或花费数小时的XML意大利面(NHibernate方法),您只需将属性放在模型类上
您甚至可以为您提供ActiveRecord generate the database schema。
我们现在已经在很多项目中使用了这种方法,其好处如下:
答案 9 :(得分:3)
我认为你几乎已经钉了它。 Subsonic生成代码,因此您的业务对象将反映您的数据库结构。 nHibernate使用映射文件将您的业务对象映射到数据库,以便您可以按照自己喜欢的方式构建对象。
这个项目有多大?是否需要长期支持? Subsonic的成本效益是否会抵消任何潜在的扩展问题?
答案 10 :(得分:3)
我们用亚音速启动,现在正试图评估我们是否会转向nhibernate现在我们处于亚音速的痛点。
我们的另一个选择是创建一些中间点,我们使用亚音速来查询和加载任意对象及其“执行类型列表”功能,该功能执行基于名称的任意linq样式sql语句的映射。或者尝试在nhibernate中重新创建一些,然后重构其余部分。
所以我认为亚音速在小型应用程序中很有意义,但亚音速应用程序的维护变得非常繁琐,我们在重叠验证代码和代码触发事件的前/后时特别困难。对于一个活跃的记录模式,亚音速肯定是80%,但是会以一种不稳定的方式做事,并阻止你对你的继承层次结构进行任何真正的控制,因为每个类都必须继承一个表来回到那个表。
答案 11 :(得分:3)
在考虑ActiveRecord时考虑您的团队和项目规模。
根据我的经验,ActiveRecord是一个基于NHibernate的抽象,在尝试更复杂的场景时会像筛子那样开始泄漏。
如果你有一个中等到复杂或非直接的架构,坚持使用NHibernate。你可以将它切成几乎完美的切片。
您可能遇到麻烦的另一个地方是您需要一个中等复杂的查询。 ActiveRecord隐藏了很多NHibernate的实现......但是你需要它来进行复杂的查询,如果你完全不熟悉HQL,这将变得非常困难。小心团队成员不要只是在边缘而不是学习NHibernate和HQL。
答案 12 :(得分:2)
拥抱阻抗不匹配!
:)
或者不。如果您想要表现,请自己动手。如果您想快速轻松,请使用NHibernate和ActiveRecord。如果你喜欢假装你真的知道在数据访问级别上发生了什么,那么使用NHibernate并整天坐在XML上以获得很多很多...或者只是......错误...自己做 - ADO.Net FTW!
答案 13 :(得分:2)
我相信你应该坚持一个你可以利用最好的。最终目标是生产力和良好的质量代码。如果你知道SubSonic进出,那么坚持下去,如果你知道NHibernate深入了解NHibernate。这是非常主观的问题。您还应该考虑您的团队成员具有专业知识的事实。如果你擅长它,你将能够轻松地维护它。
我见过使用SubSonic的大型项目,而NHibernate已经广为人知并广泛使用。
选择ORM的决定 完全取决于ORM本身。
答案 14 :(得分:0)
我对这个主题的建议是,Subsonic不会扩展到处理更复杂的场景,所以如果你走这条路,你最终会找到一份试图交换到更高级的ORM的工作。
因此我更感兴趣的是将NHibernate用于复杂的情况,使用Castle Active Record来处理更简单的情况,并关注Fluent NHibernate,这将使NHibernate映射变得更加容易(特别是一旦基于约定的映射支持得到改进)。