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 来支持他们的请求。它们获取数据并将其映射到对象（有时还提供更多内容 - 请在下面查看）。

我想指出其中的三个。它们全部在单个代码文件中提供，而不是作为编译的 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类型是一种祝福，但从长远来看，它们也是一种诅咒。