亚音速 ORM 体验答案

【问题标题】：Subsonic ORM experience亚音速 ORM 体验
【发布时间】：2011-06-08 18:15:56
【问题描述】：

我正在为一个重要项目寻找新的 ORM，我习惯于使用 ActiveRecord 进行 nHibernate，并且我已经对 EF4、性能和崩溃的 GUI 有非常糟糕的体验。

所以在网上搜索我找到了 Subsonic，我喜欢我在文档中看到的内容。

所以，我想知道是否有人已经使用过 Subsonic，体验是否良好。

【问题讨论】：

我喜欢 Subsonic 的外观，但我只使用了 nHibernate，据我所知，它是大多数 ORM 的超集......并且使用它的 Fluent 版本，我发现 nHibernate 非常友好使用。

标签： c# .net orm subsonic

【解决方案1】：

嗯……嗯……怎么说呢……

我目前（就像现在一样）正在努力将 SubSonic 替换为 PetaPoco。我想这说明了什么。

并不是说 SubSonic 很糟糕，而是它不太适合我的开发方式。对于希望在这一点上采用它的人来说，注意该项目绝对缺乏活动似乎非常很重要。

首先，SubSonic 不适合我的最大原因是 LINQ。

可以肯定的是，让编译器检查所有属性的使用是很有吸引力的。但是，在实践中，它根本不适合查询。

如果您非常坚持使用每表类和 ActiveRecord，我想没问题。但是，每当我们必须进行任何超出此范围的查询（任何涉及多个表或任何超出最简单的 where 子句的查询）时，这都是一场噩梦。关联不能直接在 SubSonic LINQ 查询中使用，就像在 EF 或 nHibernate 中一样，这可能是最大的痛点。

例如，这样的查询将不在 SubSonic 中工作，但在 EF 中可以：

db.Accounts.Where(a => a.OwningUser.Email != null);

我最终的结果要么是对数据库进行多次往返以组装结果，要么使用 SubSonic 的 CodingHorror 类直接使用 SQL 进行查询，并且无法简单地将它们具体化为POCO（再次，当超越简单的每表类时）。

我还发现每个 LINQ 提供程序都支持不同的操作集，有时相同的逻辑操作在提供程序之间的语法和使用会略有不同。这使得编写大多数查询非常耗时且容易出错。 SubSonic 的 LINQ 提供程序不乏古怪和功能不足的问题。在支持的操作、可用性或执行速度方面，它与 Linq-2-SQL、实体框架或 LINQ 相去甚远（准备好学习在 LINQ 中为 SubSonic 编写连接的新方法 - @ 987654322@).

除了拖累生产力之外，很容易忘记您正在编写的 LINQ 代码是非常特定于提供商的。 ANSI SQL远比 LINQ 更加标准和交叉兼容。

LINQ 还用规范等技术重用代码的可能性吸引了我，但充实这些远非易事，最终结果甚至不值得付出努力。我在这里遇到的障碍主要是因为 SubSonic 的 LINQ 提供程序不支持关联。

我觉得 SubSonic 在 LINQ 之外的设施充其量只是平庸（在我看来）。

其次，重要的是要知道 SubSonic 无论如何都不是一个活跃的项目。

SubSonic 的最初创建者 Rob Conery 不再参与该项目。 The last commit Rob made was in July 2010.

The last commit to the project at all was 3 months ago，despite nearly 100 outstanding issues。据我所知，自从 Rob 停止从事 SubSonic 工作以来，还没有发布任何版本，甚至没有发布小版本（尽管仍然在项目中闲逛的人一直是 talking about a release for more than half a year）。

The Google Group for SubSonic 曾经很活跃，但现在不那么活跃了。还有~~the official website for the SubSonic project has been yellow-screening-of-death for a while~~（网站不再是黄屏）。

数据访问的新热点是微 ORM。实际上，SubSonic 的创建者通过Massive 开启了这一趋势，紧接着 StackExchange 工作人员发布了Dapper，后来又出现了PetaPoco。还有几个。虽然我们通过在我们的代码库中添加 SQL sn-ps 来放弃一点编译器检查，但我发现 micro-ORM 比 SubSonic 更适合我的开发风格。

我对 nHibernate 的体验（尽管有限）是，它在大多数情况下都过于复杂，即使在合适的情况下，它也绝对扼杀了我的应用程序启动时间。还有一个很高的学习曲线（你可能已经过去了），但也有几种方法可以做......基本上一切......所以它只是在我的过程中增加了更多的决定（让我慢下来）。

使用 PetaPoco，我可以编写熟悉的 SQL - 我很快而且相当擅长 - 并将它们具体化为 POCO，我立即知道该怎么做。稍加一点架构和组织以及自动化集成测试，我一点也不觉得嵌入 SQL 有点脏。

哦，我想最后一件事 - SubSonic 远不是获取数据的最快方式。可能并不重要，但事实证明它对我们来说很重要。

总结（对不起文字墙）：

从绝对意义上说，SubSonic 并不是坏事。它似乎根本不适合我尝试使用它的方式——其中很大一部分是因为 LINQ 仍然是一个泄漏的抽象，而且它的泄漏方式与我习惯的不同。

开发工作几乎不存在这一事实是好是坏。好，它是稳定的，在某种意义上被认为是“完成”。不好，它缺少功能，可能有一些错误，而且性能不是最好的——而且没有人在努力改进它。

【讨论】：

您的回答中有一些很好的信息，但也有一些主观性。 Rob 并没有停止在 SubSonic 上的工作。这可能不是他的重点，但他在帖子和播客中说了很多（尽管他当然可以比我更好地回答这个问题）。我想第二部分是他总是说你可以做任何你想做的事情，因为你有源代码。我想这样我们 MS 开发人员还没有接受典型的开源哲学。此外，不确定您使用的是什么版本，但您始终可以使用 ToList 并轻松使用 LINQ。
我很乐意承认我所写的内容包含一些主观性，我希望我的措辞能说明这一点。查看 SubSonic 的公共存储库并告诉我 Rob（或任何人）最后一次提交（这是修辞）。最后，说使用 ToList 是非常不切实际的。非常不切实际。
我将添加更多信息，显示该项目缺乏活动。
+1 详细介绍了您对 PetaPoco 的使用，PetaPoco 是迄今为止我在 DAL 领域中除 EntityFramework 4.1 之外最有趣的项目之一。我也有使用 PetaPoco 进行生产的应用程序。我发现 PetaPoco 的 DSL 是所有微 ORM 中最好的。它直截了当，不限制你的功能，它让你可以使用最少的手写 sql，这基本上是人类可能的。
非常有趣的帖子 +1。那么微型 ORM 支持快速开发的主要吸引力是不是在没有 ORM 妨碍的情况下进行快速而准确的编码？为什么有人要使用它而不是 EF 4.1 POCO？更简单？

【解决方案2】：

前段时间，我正在为一个小型应用程序寻找一个简单的 ORM，而 SubSonic 正是我所需要的。设置很简单，我不需要太多时间来为我的域类添加一些持久性。我喜欢它的地方是可以选择基于域类自动迁移数据库模型。

它的缺点是功能集相当有限。我最想念的是获取完整对象图的选项和对附加索引的支持。 SubSonic 将其用作小型应用程序的持久性工具，但对于重要或大型应用程序，我宁愿使用 nHibernate 或像 LLBLGen 这样的商业 ORM。

在选择 ORM 之前，您应该确定基本的数据访问要求。你想使用 Active Record 模式还是 Adapter 模式？并发、性能、继承等呢……

【讨论】：

【解决方案3】：

我用的是 Supersonic，只要你使用简单的查询就很好。当我开始处理更复杂的查询时，我发现它缺少 LINQ 功能。在谷歌上搜索了一下之后，我切换到了http://bltoolkit.net，从那时起（大约 2 年了）我对它非常满意。根据http://ormeter.net/，Plus 是最快的 ORM 之一。看看吧，你不会后悔的。

【讨论】：