支持存储过程的 BLToolkit 替代对象映射器

Question

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

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

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

缺点

BLToolkit

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

问题

我有什么替代方案可以替代BLToolkit：

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

基本上

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

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

Answer 1

替代方案（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） 和缓存的 - 如果您使用大量类型，这也可能是缺点）
• 大量 - 由罗伯康纳利撰写;
  • 仅支持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类型是一种祝福，但从长远来看，它们也是一种诅咒。