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

Question

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

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

基本上，我所有的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接口(interface)的连接类，它就支持任何后备数据存储。

使用参数化的SQL

映射到静态类型以及dynamic(.net 4+)

支持每个结果记录映射到多个对象(如1-1关系，即Person + Address)

支持多结果对象映射

支持存储过程

映射被生成，编译(MSIL)和缓存-如果您使用大量类型，这也可能是不利的)

Massive-由罗伯·康纳利(Rob Connery)撰写；

仅支持dynamic类型映射(在.net 3.5或更高版本的婴儿中不支持)

非常小(几百行代码)

提供了您的实体继承的DynamicModel类，并从任意裸机TSQL

提供了CRUD功能 或映射

隐式分页支持

支持列名映射(但是每次访问数据而不是声明性属性时，您都必须这样做)

通过编写直接参数化的TSQL

支持存储过程

PetaPoco-启发了我的Massive，但需要支持较旧的框架版本

支持强类型以及dynamic

提供了用于生成POCO的T4模板-您将获得与大型ORM相似的类(这意味着不支持代码优先)，但是您不必使用这些，您仍然可以编写自己的POCO当然可以使您的模型保持轻量级的类，而不包括仅DB的信息(例如，时间戳等)。

类似于Dapper的

，它还编译映射以提高速度并重用

支持CRUD操作+ IsNew

隐式分页支持，该方法返回一种特殊类型，其中包含数据已满的页面+所有元数据(当前页面，所有页面/记录的数量)

具有针对各种场景(日志记录，类型转换器等)的可扩展点

支持声明性元数据(列/表映射等)

支持通过某些自动关系设置(与Dapper中必须手动连接相关对象的情况不同)对每个结果记录进行多对象映射

支持存储过程

有一个辅助SqlBuilder类，可以更轻松地构建TSQL语句

在这三个方面中，PetaPoco似乎是最活跃的，并且通过充分利用其他两个(以及其他一些)中的最好功能来支持大多数事物。

在这三者中，Dapper具有最佳的实际使用情况引用，因为它被世界上流量最高的站点之一使用:Stackoverflow。

它们都遭受魔术字符串问题的困扰，因为大多数时候您直接将SQL查询写入其中。但是T4可以缓解其中的一些问题，因此您可以拥有强大的类型化调用，这些调用可以在Visual Studio中即时提供智能感知，编译时检查和重新生成。
dynamic类型的缺点

我认为 dynamic类型的最大缺点是维护。想象一下使用动态类型的应用程序。过一会儿再看自己的代码会变得很麻烦，因为您没有要观察或坚持的具体类。从长远来看，尽管 dynamic类型很幸运，但它们也是一个诅咒。