c# - 亚音速 ORM 体验

Question

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

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

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

Answer 1

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

我目前(就像现在一样)正在努力用 PetaPoco 替换 SubSonic 。我想这说明了什么。

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

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

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

如果您非常坚持使用 class-per-table 和 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、Entity Framework 或 LINQ to nHibernate 相去甚远(准备好学习在 LINQ 中为 SubSonic 编写连接的新方法 - and be ready to have some common operations simply not be possible with SubSonic's LINQ provider, despite being known bugs for a year )。

除了对生产力的拖累之外，很容易忘记您正在编写的 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 片段来放弃一些编译器检查，但我发现 micro-ORM 比 SubSonic 更适合我的开发风格。

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

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

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

总结(对不起文字墙):

并不是说 SubSonic 在任何绝对意义上都不好。它似乎根本不适合我试图很好地使用它的方式 - 其中很大一部分是因为 LINQ 仍然是一个有漏洞的抽象，并且它以与我习惯的不同方式存在漏洞。

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