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

Question

我并不是直接实体映射器的粉丝，因为我仍然认为SQL查询是最快的，并且在手工直接写入数据库时​​使用最优化（使用正确的连接，分组，索引等）。

在我目前的项目中，我决定尝试BLToolkit，我对它的Ado.net和速度包装非常满意，所以我查询数据库并获得强大的C＃类型对象。我还写了一个T4 that generates stored procedure helpers所以我在调用存储过程时不必使用魔术字符串，所以我的所有调用都使用强类型参数。

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

下行

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

问题

我对BLToolkit有哪些替代方案：

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

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

最重要的要求：易于使用，受到良好支持，社区也在使用。

Answer 1

替代方案（2011年5月）

我可以看到大枪已将其访问策略转换为微型ORM工具。当我评估BLToolkit时，我正在玩同样的想法，因为它对我使用的功能感觉笨重（1.5MB）。最后，我决定编写前面提到的T4（有问题的链接），以便在调用存储过程时更轻松。但BLToolkit中仍有许多可能性，我完全不使用甚至不理解（原因也在问题中指出）。

最佳选择是 micro 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类，并从任意裸金属TSQL提供CRUD功能或地图
  • 隐式分页支持
  • 支持列名映射（但每次访问数据时都必须这样做，而不是声明性属性）
  • 通过编写直接参数化TSQL
  来支持存储过程
• PetaPoco - 启发了我的Massive，但要求支持较旧的框架版本
  • 支持强类型以及dynamic
  • 提供T4模板来生成您的POCO - 您将最终获得与大型ORM类似的类（这意味着代码优先不受支持）但您不必使用这些您仍然可以编写自己的POCO课程，以保持模型的轻量级，而不包括仅限数据库的信息（即时间戳等）。
  • 类似于Dapper，它还编译速度和重用的映射
  • 支持CRUD操作+ IsNew
  • 隐式分页支持，返回一个特殊类型，其中包含数据页面+所有元数据（当前页面，所有页面/记录的数量）
  • 具有各种方案的可扩展性点（日志记录，类型转换器等）
  • 支持声明性元数据（列/表映射等）
  • 支持使用某些自动关系设置对每个结果记录进行多对象映射（与Dapper不同，您需要手动连接相关对象）
  • 支持存储过程
  • 有一个帮助器SqlBuilder类，可以更轻松地构建TSQL语句

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

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

他们都遇到魔术字符串问题，因为您在大多数时间直接将SQL查询写入其中。但其中一些可以通过T4减轻，因此您可以使用强类型调用，在Visual Studio中动态提供智能感知，编译时检查和重新生成。

dynamic类型

的下行

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