6

我不太喜欢直接实体映射器，因为我仍然认为直接在数据库上手动编写 SQL 查询是最快和最优化的（使用正确的连接、分组、索引等）。

在我当前的项目中，我决定尝试一下 BLToolkit，我对它围绕 Ado.net 的包装器和速度非常满意，因此我查询数据库并获取强类型 C# 对象。我还编写了一个生成存储过程助手的 T4，因此在调用存储过程时我不必使用魔术字符串，因此我所有的调用都使用强类型作为参数。

基本上我所有的 CRUD 调用都是通过存储过程完成的，因为我的许多查询不是简单的选择语句，尤其是我的创建和更新也返回结果，这很容易使用存储过程进行一次调用。反正...

缺点

BLToolkit 的最大缺点（我希望每个评估 BLToolkit 的人都知道这一点）不是它的功能或速度，而是它非常稀缺的文档以及支持或缺乏支持。所以这个库的最大问题是反复试验以使其正常工作。这就是为什么我也不想使用太多不同的部分，因为我使用的越多，我必须自己解决的问题就越多。

问题

我对 BLToolkit 有什么替代方案：

  • 支持使用返回我提供的任何实体的存储过程，这些实体不一定与数据库表相同
  • 提供从数据读取器到对象的漂亮对象映射器
  • 支持关系（全部）
  • 对多个结果集结果的可选（但可取）支持
  • 不需要任何特殊配置（我只使用数据连接字符串，没有别的）

基本上它应该是非常轻量级的，基本上应该只有一个简单的 Ado.net 包装器和对象映射器。

最重要的要求：易于使用，得到很好的支持并且社区使用它。

4

1 回答 1

4

替代品（2011 年 5 月）

我可以看到大佬们已经将他们的访问策略转换为微型 ORM 工具。当我评估 BLToolkit 时，我也在玩同样的想法，因为对于我要使用的功能来说，它感觉很笨重（1.5MB）。最后，我决定编写前面提到的 T4（有问题的链接），以便在调用存储过程时让我的生活更轻松。但是BLToolkit内部仍然有很多我根本不使用甚至不理解的可能性（问题中也指出了原因）。

最好的选择是微型 ORM工具。也许将它们称为微对象映射器会更好。他们都有相同的目标：简单和极速。他们没有遵循他们的大同胞 ORM 的NoSQL范式，所以大多数时候我们必须（几乎）每天编写 TSQL 来支持他们的请求。他们获取数据并将它们映射到对象（有时会提供更多信息 - 请查看下方）。

我想指出其中的 3 个。它们都在单个代码文件中提供，而不是作为编译的 DLL：

  • Dapper - 由Stackoverflow本身使用；它实际上所做的一切都提供了通用扩展方法，IDbConnection这意味着它支持任何支持数据存储，只要有一个实现IDbConnection接口的连接类；
    • 使用参数化 SQL
    • 映射到静态类型以及dynamic（.net 4+）
    • 支持映射到每个结果记录的多个对象（如 1-1 关系，即Person+ Address）
    • 支持多结果集对象映射
    • 支持存储过程
    • 生成、编译 (MSIL) 和缓存映射 - 如果您使用大量类型，这也可能是不利的）
  • Massive - 由 Rob Connery 撰写；
    • 仅支持dynamic类型映射（.net 3.5 或更早版本不支持）
    • 非常小（几百行代码）
    • 提供DynamicModel您的实体继承的类，并提供 CRUD 功能或来自任意裸机 TSQL 的映射
    • 隐式分页支持
    • 支持列名映射（但每次访问数据时都必须这样做，而不是声明性属性）
    • 通过编写直接参数化的 TSQL 来支持存储过程
  • PetaPoco - 启发了我的 Massive，但需要支持旧的框架版本
    • 支持强类型以及dynamic
    • 提供 T4 模板来生成你的 POCO——你最终会得到与大型 ORM 类似的类（这意味着不支持代码优先） 但你不必使用这些你仍然可以编写自己的 POCO 类当然保持您的模型轻量级并且不包括仅数据库信息（即时间戳等）
    • 与 Dapper 类似，它还编译映射以提高速度和重用性
    • 支持 CRUD 操作 +IsNew
    • 隐式分页支持，返回一个特殊类型的页面充满数据+所有元数据（当前页面，所有页面/记录的数量）
    • 具有适用于各种场景（日志记录、类型转换器等）的扩展点
    • 支持声明性元数据（列/表映射等）
    • 通过一些自动关系设置支持每个结果记录的多对象映射（与必须手动连接相关对象的 Dapper 不同）
    • 支持存储过程
    • 有一个帮助SqlBuilder类，可以更轻松地构建 TSQL 语句

在所有三个中，PetaPoco 似乎在开发方面是最活跃的，并且通过充分利用其他两个（以及其他一些）来支持大多数事情。

在所有三个中，Dapper 具有最佳的实际使用参考，因为它被世界上流量最高的站点之一使用：Stackoverflow。

它们都遭受魔术字符串问题的困扰，因为您大部分时间都将 SQL 查询直接写入它们。但其中一些可以通过 T4 缓解，因此您可以在 Visual Studio 中进行强类型调用，提供智能感知、编译时检查和动态重新生成。

dynamic类型的缺点

我认为dynamic类型的最大缺点是维护。想象一下您的应用程序使用动态类型。一段时间后查看自己的代码会变得相当有问题，因为您没有任何具体的类可以观察或坚持。尽管dynamic类型是一种祝福，但从长远来看，它们也是一种诅咒。

于 2011-05-18T08:16:05.157 回答