亚音速与NHibernate
什么时候使用这些工具中的一种转向另一种工具呢？ 我发现Subsonic在快速完成任务方面非常有用，但在大型项目中，它往往不能扩展，它将您的领域模型与数据库模型联系在一起。 这就是Nhibernate进来的地方，因为它提供了与您的数据库模型无关的轻量级POCO，但是安装时间要长得多。
我被问了很多这个问题，真正归结为你想要的小提琴。 我不能告诉你如何破坏克里斯·塞瓦斯的评论RE SubSonic缩放已经 – 我一直在回应这些以来:(：
交易是 – perf-wise，SubSonic非常好地缩放。 就项目增长而言 – 您使用的任何工具都需要您的关注。 即使NHibernate。
我写了一篇关于如何在SubSonic 2.1中使用Repository模式的文章（就像你使用NHIb或者其他工具一样）：
http://blog.wekeroad.com/blog/subsonic-writing-decoupled-testable-code-with-subsonic-2-1/
我还写了一篇关于SubSOnic表演的文章：
http://blog.wekeroad.com/blog/subsonic-scaling/
希望这可以帮助。
如果您的项目与ActiveRecord视图一起使用，则build议使用SubSonic，即数据库是您的模型。 你会得到每桌一个类，一切都只是神奇的作品。 你当然可以调整和重写的东西，但如果你（或你的项目）从根本上不同意每class表的方法，我会看看NHibernate，因为它开始于更复杂（但更灵活）的方法映射域模型到您的数据库。
如果你正在使用一个相对简单的数据库（如在你的控制下，你可以改变列而不发送八个表格到数据库部门监督审查委员会），我build议从SubSonic开始，如果SubSonic没有转移到NHibernate满足您的需求。
对于它的价值…自问这个问题以来，我有机会使用这两种技术。 我必须留下来，如果你select的这些技术很less。 当然，NHibernate允许你的业务实体与你的数据库结构稍微有点不同，但是我仍然发现在很多情况下你仍然必须屈从于数据库的意愿。
在我看来，从数据库模型完全分离领域模型的唯一方法是编写自己的DTOS （实质上是用于传递数据的POCO），然后将它们映射回您的数据层中select的ORM。 但是在大多数情况下，这种方法会让我比它的价值更麻烦。
稍微偏离主题，但以相似的方式。 你看过Castle ActiveRecord，它是在NHibernate的基础上编写的，无需花费时间从代码创buildXML映射到数据库。 和NHibernate一样，您可以根据需要构build域对象，然后从此结构生成数据库模式。
使用ActiveWriter ，一个贡献工具，您可以轻松地从您的数据库映射到域对象。
你可以考虑看一下stream利的NHibernate; 它使pipe理NHibernate轻而易举。 不知道转换现有的模式是多么的困难，但是如果你正在构build一个新的应用程序，那么定义域模型并在几乎所有你能想到的数据库服务器中生成数据库都不错。 从阅读这里的其他评论，我认为stream利的NHibernate使NHibernate与SubSonic相提并论，便于configuration。
我不能给一个很好的比较，因为我还没有实际上在一个项目上使用NHibernate，但我已经使用SubSonic，并已经非常满意。 到目前为止，我使用它时没有遇到任何重大障碍。
看看SubSonic的创造者之一Rob Conery的这篇文章 。 他谈到如何从应用程序的其余部分分离您的SubSonic代码。 他甚至提到了这样一个事实：这个架构可以让你稍后将SubSonic换成其他数据访问层，例如NHibernate或LINQ to SQL。
我知道我没有真正回答你的问题，但我希望这仍然有帮助。
我最近写了一篇关于.NET中的ORM 的博文，里面有Subsonic和ActiveRecord。 从我的经验来看，这取决于项目在做什么，如果你来自SQL背景，Subsonic的工作要好得多，但是NHibernate有更多的优势。 ActiveRecord对于较小的项目是很好的，我不相信对于大型项目来说，比坚持NHibernate更快。
我已经评估过，我相信如果不明白你的目标是什么，那么推荐一个就不公平了。 在你的问题上，你说的差异很好，我相信这需要成为你决定的因素。 就我个人而言，我已经使用，并将继续使用两个取决于项目。
- NHibernate是大型项目的select，因为它使用轻量级POCO。 如果我要把我的ORM切换出来，“我相信”这会更容易重构。
- 当我有一个较小规模的项目时，SubSonic是我的select。 我相信SubSonic的性能performance非常好。 不过，我觉得它是紧密结合在一起的，因为它是如此刻在我的项目。 在较小的项目中，我仍然可以将其切换出来，因为代码基数非常小，并且可以帮助我将广告中的代码拆分出来。
我觉得你几乎是钉上了它。 Subsonic生成代码，所以您的业务对象将反映您的数据库结构。 nHibernate使用将业务对象映射到数据库的映射文件，因此您的对象可以按照您的喜好进行结构化。
这个项目有多大？ 是否需要长期支持？ Subsonic的成本效益是否会抵消任何潜在的扩展问题？
再次稍微离题，但我会再次Castle ActiveRecord – 而不是使用数据库作为你的模型（Subsonic方法）或花费在XML意大利面（NHibernate的方法）小时，只需将属性放在您的模型类。
你甚至可以让ActiveRecord为你生成数据库模式 。
我们现在已经在很多项目中使用了这种方法，其好处如下：
- 如果将来需要，可以轻松升级到NHibernate
- 支持简单的inheritance模型 – 例如。 汽车 – >车辆
- 它生成的模式很可能是你创build它的方式，所以你可以花更多的时间来构build应用程序，而不用担心保持你的模型/数据库同步。
我们用亚音速引导，现在正在试图评估我们现在是否处在亚音速的痛点之下，是否将转向北极。
我们的另一个select是创build一些中间地带，我们使用亚音速来查询和加载任意对象的“执行types列表”function，该function执行基于名称的映射closures任意linq样式的sql语句。 或者尝试在nhibernate中重新创build其中的一部分，然后重构其余部分。
所以我说亚音速在小应用程序中是有意义的，但亚音速应用程序的维护变得非常多毛，特别是有重叠validation代码的困难时期，以及在代码触发事件中的预/后期。 对于一个活跃的logging模式，亚音速绝对是80％，但是却有些片面，并且阻止了对inheritance层次的真正控制，因为每个类都必须inheritance一个表才能返回该表。
在考虑ActiveRecord时考虑你的团队和项目大小。
根据我的经验，ActiveRecord是NHibernate的一个抽象概念，在尝试更复杂的场景时会像筛一样泄漏。
如果你有一个适度到复杂或非直接的模式，坚持使用NHibernate。 你可以把它切成几乎完美的。
另一个可能会遇到麻烦的地方是当你需要一个适度复杂的查询时。 ActiveRecord隐藏了许多NHibernate的实现…但是你需要它来完成一个复杂的查询，如果你完全不熟悉HQL，这将变得非常困难。 小心团队成员不要在学习NHibernate和HQL的时候攻破边缘。
我相信你应该坚持一个你可以利用最好的。 最终目标是生产力和良好的执行质量代码。 如果你知道SubSonic进出，那就坚持下去，如果你深入了解NHibernate的话，坚持NHibernate。 这是非常主观的问题。 你还应该考虑到你的团队成员有什么专长。 如果你擅长它，你将能够轻松地维护它。
我见过使用SubSonic的大型项目，而NHibernate已经很有名，并且被广泛使用。
selectORM的决定并不 完全取决于ORM本身。
拥抱阻抗不匹配！
看一下这个
🙂
或者不要。 如果你想要表演，请自己动手。 如果你想快速简单的使用NHibernate和ActiveRecord。 如果你想假装你真的知道在数据访问级别发生了什么事情，那么使用NHibernate，并整天坐在XML上，以获得多到多的…或者只是…错误…自己动手 – ADO.Net FTW！
我在这个话题上得到的build议是，Subsonic不能扩展来处理更复杂的场景，所以如果你顺着这条道路走下去，那么最终你会得到一个尝试转换到更高级的ORM的工作。
因此，我更感兴趣的是在复杂情况下使用NHibernate，为更简单的情况使用Castle Active Record，并且关注Fluent NHibernate，这应该使NHibernate映射更容易（尤其是一旦基于约定的映射支持得到改进）。
