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

解决方案

回答

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

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

回答

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

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

回答

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

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

回答

我们已经陷入亚音速的困境，现在我们正尝试评估是否要进入亚音速状态，因为我们正处于亚音速的痛苦之中。

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

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

回答

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

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

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

回答

我经常被问到这个问题，实际上归结为我们想花多少钱。我无法告诉我们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/

希望这可以帮助。

回答

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

我们甚至可以让ActiveRecord为我们生成数据库架构。

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

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

回答

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

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

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

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

回答

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

回答

我得到的关于该主题的建议是Subsonic不能扩展以处理更复杂的场景，因此，如果走那条路，我们将最终会尝试转换为更高级的ORM。

因此，我对在复杂情况下使用NHibernate，在简单情况下使用Castle Active Record更加感兴趣，并且一直关注Fluent NHibernate，这将使NHibernate映射更加容易(尤其是在改进了基于约定的映射支持之后)。

回答

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

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

回答

拥抱阻抗不匹配！

看一下这个

:)

还是不要。如果我们想要性能，请自己做。如果我们想快速简便地使用NHibernate和ActiveRecord。如果我们想假装自己实际上知道数据访问级别正在发生什么，请使用NHibernate并整日坐在XML上，以实现很多对很多...或者只是... er .. ！

回答

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

回答

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

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

回答

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

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

The decision of picking ORM does not
  solely depend on the ORM itself.