Subsonic 与 NHibernate

Question

对于何时使用这些工具中的一种而不是另一种的共识是什么？我发现 Subsonic 在快速完成工作方面非常有用，但在大型项目中它往往无法扩展，并且它将您的领域模型与数据库模型联系起来。这就是 Nhibernate 的用武之地，因为它为您提供与数据库模型无关的轻量级 POCO，但设置时间要长得多。

Answer 1

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

就性能而言，SubSonic 的扩展性非常好。就项目增长而言 - 您使用的任何工具都需要您的关注。甚至NHibernate。

我写了一篇关于如何在 SubSonic 2.1 中使用存储库模式和 DI 的文章（就像使用 NHIb 或任何相关工具一样）：

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

我还写了一篇关于 SubSonic 性能的文章：

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

希望这可以帮助。

Answer 2

如果您的项目使用 ActiveRecord 视图（数据库是您的模型），我会推荐 SubSonic。每桌你会得到一堂课，一切都会神奇地进行。你当然可以调整和覆盖一些东西，但是如果你（或你的项目）从根本上不同意每表类的方法，我会考虑NHibernate，因为它从映射你的更复杂（但更灵活）的方法开始。域模型到您的数据库。

如果您使用的是在您控制之下的相对简单的数据库（例如，您可以更改列，而无需向数据库部门监督审查委员会发送八个表格），我建议您从 SubSonic 开始，如果 SubSonic 不支持，则迁移到 NHibernate满足您的需求。

Answer 3

对于它的价值......自从提出这个问题以来，我有机会更多地使用这两种技术。如果你选择的这些技术无关紧要，我必须留下来。当然，NHibernate 允许您的业务实体稍微减少与数据库结构的耦合，但我仍然发现在很多情况下您仍然必须屈服于数据库的意愿。

在我看来，将领域模型与数据库模型完全分离的唯一真正方法是编写自己的模型 DTOS （本质上是用于传递数据的 POCO），然后将它们映射回数据层中您选择的 ORM。但在大多数情况下，这种方法给我带来的麻烦远大于它的价值。

Answer 4

有点偏离主题，但风格类似。你看过吗 城堡活动记录 它写在上面 NHibernate 并且无需花费时间创建从代码到数据库的 XML 映射。与 NHibernate 一样，您可以根据需要构造域对象，然后根据该结构生成数据库模式。

使用 活动作家, ，一个贡献的工具，您可以轻松地从数据库映射到域对象。

Answer 5

您可以考虑查看 Fluent NHibernate；它使得 NHibernate 的管理变得轻而易举。不确定转换现有模式有多困难，但如果您正在构建新的应用程序，那么最好在您能想到的几乎任何数据库服务器中定义域模型并生成数据库。通过阅读这里的其他评论，我认为 Fluent NHibernate 使 NHibernate 与 SubSonic 一样易于配置。

Answer 6

我无法给出一个很好的比较，因为我还没有在项目中实际使用过 NHibernate，但我已经使用过 SubSonic 并且对它非常满意。到目前为止，我在使用它时还没有遇到任何重大障碍。

查看 这个帖子 来自 SubSonic 的创作者之一 Rob Conery。他讨论了如何将 SubSonic 代码与应用程序的其余部分分离。他甚至提到，这种架构使您能够稍后将 SubSonic 替换为其他一些数据访问层，例如 NHibernate 或 LINQ to SQL。

我知道我实际上没有回答你的问题，但我希望这仍然有帮助。

Answer 7

我 写了一篇博文 最近关于 .NET ORM，其中有 Subsonic 和 ActiveRecord。根据我的经验，这取决于项目正在做什么，如果你有 SQL 背景，Subsonic 会工作得更好，但 NHibernate 有更多的基础。ActiveRecord 适合较小的项目，我不相信它对于较大的项目比坚持使用 NHibernate 更快。

Answer 8

我对两者都进行了评估，我相信在不了解您的目标是什么的情况下推荐其中之一是不公平的。在你的问题中，你很好地阐述了差异，我相信这需要成为你的决定因素。就我个人而言，我已经使用了这两种方法，并将根据项目继续使用这两种方法。

• NHibernate 是我对于大型项目的选择，因为它使用轻量级 POCO。如果我“我相信”更换了我的 ORM，那么重构会容易得多。
• 当我有一个较小规模的项目时，SubSonic 是我的选择。我相信 SubSonic 的性能可以很好地扩展。然而，我感觉与它紧密相连，因为它是如此铭刻在我的项目中。在较小的项目中，我仍然可以将其切换出来，因为代码库很小，而且它确实可以帮助我删除广告中的代码。

Answer 9

再次有点偏离主题，但我会其次 城堡活动记录 - 无需使用数据库作为模型（Subsonic 方法）或花费大量时间研究 XML Spaghetti（NHibernate 方法），您只需将属性放在模型类上即可。

您甚至可以获取 ActiveRecord 生成数据库模式 为你。

我们现在已经在相当多的项目中使用了这种方法，其好处如下：

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

Answer 10

我认为你已经成功了。Subsonic 生成代码，因此您的业务对象将反映您的数据库结构。nHibernate 使用映射文件将您的业务对象映射到数据库，这样您的对象就可以按照您喜欢的方式构建。

这是一个多大的工程？是否需要长期支持？Subsonic 的成本效益是否能够抵消任何潜在的规模问题？

Answer 11

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

我们的另一个选择是创建一些中间立场，我们使用 subsonic 来查询和加载任意对象，并使用其“按类型列表执行”功能，该功能对任意 linq 样式 sql 语句进行基于名称的映射。或者尝试在 nhibernate 中重新创建其中一些并重构其余部分。

所以我说亚音速在小型应用程序中是有意义的，但是亚音速应用程序的维护变得非常棘手，我们在重叠验证代码以及代码触发事件中的前/后方面遇到了特别困难的时期。对于活动记录模式，亚音速绝对是 80%，但是以不稳定的方式执行某些操作，并且阻止您对继承层次结构进行任何真正的控制，因为每个类都必须继承一个表才能返回到该表。

Answer 12

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

根据我的经验，ActiveRecord 是 NHibernate 之上的一个抽象，当尝试更复杂的场景时，它会像筛子一样开始泄漏。

如果您有中度到高度复杂或非直接的模式，请坚持使用 NHibernate。你可以把它切成近乎完美的形状。

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

Answer 13

拥抱阻抗不匹配！

看一下这个

:)

或者不这样做。如果你想要性能，那就自己做吧。如果您想要快速简单，请选择 NHibernate 和 ActiveRecord。如果您喜欢假装您实际上知道数据访问级别发生了什么，请使用 NHibernate 并整天坐在 XML 上以进行多对多操作...要不就...呃..自己动手 - ADO.Net FTW！

Answer 14

我相信你应该坚持使用最能发挥作用的一种。最终目标是生产力和良好的性能质量代码。如果您对 SubSonic 了如指掌，那么请坚持使用它，如果您深入了解 NHibernate，请坚持使用 NHibernate。这是一个非常主观的问题。您还应该考虑您的团队成员所具备的专业知识这一事实。如果你擅长它，你将能够轻松维护它。

我见过使用 SubSonic 的大型项目，而 NHibernate 已经很出名并被广泛使用。

选择 ORM 的决定并不 完全取决于 ORM 本身。

Answer 15

我在该主题上得到的建议是 Subsonic 无法扩展以处理更复杂的场景，因此如果您沿着这条路走下去，您最终会得到一份尝试切换到更高级的 ORM 的工作。

因此，我对使用 NHibernate 处理复杂的情况更感兴趣，使用 Castle Active Record 处理更简单的情况，并密切关注 Fluent NHibernate，它应该使 NHibernate 映射变得更加容易（特别是在基于约定的映射支持得到改进后）。