关于.net：Subsonic与NHibernate

Subsonic Vs NHibernate

什么时候使用其中一种工具不利于另一种工具的共识是什么？我发现Subsonic在快速完成工作方面非常有用，但是在大型项目中，它往往无法扩展，并且将您的域模型与数据库模型联系在一起。这就是Nhibernate出现的地方，因为它为您提供了与数据库模型无关的轻量级POCO，但是建立时间更长。

我经常被问到这个问题，实际上这取决于您要摆弄多少。我无法告诉您Chris Cyvas的评论RE SubSonic缩放有多有害-从那时起我一直在回应这些:(。

这笔交易是明智的，SubSonic可以很好地扩展。就项目增长而言-您使用的任何工具都需要引起您的注意。甚至NHibernate。

我写了一篇关于如何在SubSonic 2.1中将存储库模式用于DI(就像使用NHIb或其他工具一样)的文章：

http://blog.wekeroad.com/blog/subsonic-writing-decoupled-testable-code-with-subsonic-2-1/

我还写了一篇有关SubSOnic性能的文章：

http://blog.wekeroad.com/blog/subsonic-scaling/

希望这可以帮助。

如果您的项目与数据库是您的模型的ActiveRecord视图一起使用，我建议您使用SubSonic。您将在每张桌子上上一堂课，一切都神奇地起作用了。您当然可以进行调整和覆盖，但是，如果您(或您的项目)从根本上反对按表分类的方法，那么我将研究NHibernate，因为它从映射您的地图的更复杂(但更灵活)的方法开始域模型添加到您的数据库。

如果您使用的是受控的相对简单的数据库(例如，您可以在不向数据库部门监督审查委员会发送八张表格的情况下更改列)，那么我建议从SubSonic开始，如果SubSonic不这样做，则转到NHibernate。满足您的需求。

自问这个问题以来...我有机会更多地使用这两种技术。如果要选择这些技术，那么我就必须留下一点意见。当然，NHibernate可以使您的业务实体与数据库结构的耦合程度略有降低，但是我仍然发现，在很多情况下，您仍然不得不屈从于数据库的意愿。

在我看来，将域模型与数据库模型完全分开的唯一真实方法是编写自己的DTOS(基本上是用于传递数据的POCO)，然后将其映射回数据层中您选择的ORM。但是在大多数情况下，这种方法比它的价值更麻烦。

稍微偏离主题，但类似。您是否看过Castle ActiveRecord，它是在NHibernate之上编写的，因此无需花费时间来创建从代码到数据库的XML映射。像NHibernate一样，您可以根据需要构造域对象，然后从该结构生成数据库架构。

使用ActiveWriter(一种辅助工具)，您可以轻松地从数据库映射到域对象。

您可以考虑使用Fluent NHibernate。它使NHibernate的管理变得轻而易举。不确定转移现有模式会有多困难，但是如果要构建新的应用程序，最好定义域模型并在您能想到的几乎所有DB服务器中生成数据库。通过阅读这里的其他评论，我认为Fluent NHibernate可以将NHibernate与SubSonic相提并论，以便于配置。

我最近写了一篇有关.NET ORM的博客文章，其中包含Subsonic和ActiveRecord。根据我的经验，这取决于项目的工作情况，如果您来自SQL背景，那么Subsonic的工作会更好，但是NHibernate具有更多优势。 ActiveRecord对于较小的项目很有用，我不认为对于大型项目，它比坚持NHibernate更快。

由于我尚未在项目中实际使用NHibernate，因此无法给出很好的比较，但是我使用SubSonic并对此感到非常满意。到目前为止，使用它时我还没有遇到任何主要障碍。

请查看SubSonic的创建者之一Rob Conery的这篇文章。他讨论了如何将您的SubSonic代码与应用程序的其余部分分离。他甚至提到以下事实：该体系结构使您以后可以将SubSonic换成其他一些数据访问层，例如NHibernate或LINQ to SQL。

我知道我实际上没有回答您的问题，但是希望这对您有所帮助。

我对两者都进行了评估，我认为在不了解您的目标的情况下建议彼此推荐是不公平的。在您的问题中，您很好地说明了差异，我认为这是您的决定因素。我个人已经使用了这两种方法，并将根据项目继续使用这两种方法。

对于大型项目，我选择NHibernate，因为它使用了轻量级的POCO。如果我要退出我的ORM"我相信"，那么重构起来会容易得多。
当我有较小规模的项目时，SubSonic是我的选择。我相信在性能方面明智的SubSonic可以很好地扩展。但是，由于它已刻在我的项目中，因此我感到与它紧密结合。在较小的项目中，我仍然可以将其关闭，因为代码库太小了，它确实可以帮助我按广告中的说明提取代码。

还是有点题外话，但是我将第二次使用Castle ActiveRecord-而不是使用数据库作为您的模型(Subsonic方法)或花费数小时的XML意大利面条(NHibernate方法)，您只需在模型类上放置属性即可。

您甚至可以使ActiveRecord为您生成数据库架构。

现在，我们已经在许多项目上使用了这种方法，其好处如下：

如果将来需要，可以轻松升级到NHibernate
支持简单的继承模型-例如。汽车->车辆
无论如何，它生成的模式很可能是您如何创建的，因此您可以花更多的时间来构建应用程序，而不必担心保持模型/数据库同步。

在考虑ActiveRecord时，请考虑您的团队和项目规模。

以我的经验，ActiveRecord是NHibernate的抽象，在尝试更复杂的场景时会像筛子一样开始泄漏。

如果您具有中等到高度复杂或非直截了当的架构，请坚持使用NHibernate。您可以将其切成薄片并将其切成小方块。

您可能遇到麻烦的另一个地方是当您需要一个中等复杂的查询时。 ActiveRecord隐藏了很多NHibernate的实现...但是您将需要它来进行复杂的查询，如果您完全不熟悉HQL，这将变得非常困难。小心团队成员不要仅仅学习边缘知识，而不仅仅是学习NHibernate和HQL。

我们处于亚音速之路，现在我们正尝试评估是否正处于亚音速的痛点，因此是否要切换到休眠状态。

我们的另一种选择是创建一个中间立场，在这里我们可以使用subsonic来查询和加载具有"作为类型列表执行"功能的任意对象，该功能可以根据任意linq样式sql语句进行基于名称的映射。或者尝试在nhibernate中重新创建其中的一部分，然后重构其余部分。

因此，我说亚音速在小型应用程序中是有意义的，但亚音速应用程序的维护工作非常繁琐，验证代码重叠以及代码触发事件的前/后工作尤其困难。对于活动记录模式，subsonic肯定在那里占80％，但以一种不稳定的方式进行操作，并阻止您对继承层次结构进行任何实际控制，因为每个类都必须继承一个表才能返回该表。

我认为您几乎钉牢了它。 Subsonic生成代码，因此您的业务对象将反映您的数据库结构。 nHibernate使用映射文件将您的业务对象映射到数据库，以便您可以随意构建对象。

这是一个多大的项目？是否需要长期支持？ Subsonic的成本效益是否可以抵消任何潜在的扩展问题？

我相信您应该坚持使用最好的方法。最终目标是提高生产效率和提供良好的质量代码。如果您知道SubSonic的进进出出，请坚持下去，如果您知道NHibernate的深度，请坚持使用NHibernate。这是一个非常主观的问题。您还应该考虑您的团队成员具有专业知识的事实。如果您擅长于此，则可以轻松进行维护。

我已经看到了使用SubSonic的大型项目，而NHibernate已经很出名并且被广泛使用。