支持存储过程的 BLToolkit 替代对象映射器
我不太喜欢直接实体映射器，因为我仍然认为直接在数据库上手动编写 SQL 查询（使用正确的联接、分组、索引等）时速度最快且最优化。
在我当前的项目中，我决定尝试一下 BLToolkit，我对它对 Ado.net 的包装和速度非常满意，因此我查询数据库并获取强类型 C# 对象。我还编写了 T4 生成存储过程助手< /a> 所以我在调用存储过程时不必使用魔术字符串，因此我所有的调用都使用强类型作为参数。
基本上我所有的 CRUD 调用都是通过存储过程完成的，因为我的许多查询不是简单的 select 语句，特别是我的创建和更新也返回结果，这可以使用仅进行一次调用的存储过程轻松完成。不管怎样...
缺点
BLToolkit 的最大缺点（我希望每个评估 BLToolkit 的人都知道这一点）不是它的功能或速度，而是它非常稀缺的文档以及支持或缺乏。所以这个库最大的问题是不断尝试和犯错以使其正常工作。这就是为什么我也不想使用它的太多不同部分，因为我使用的越多，我必须自己解决的问题就越多。
问题
我对 BLToolkit 有哪些替代方案：
- 支持使用存储过程，该过程返回我提供的任何实体，这些实体不一定与数据库表相同
- 提供从数据读取器到对象的良好对象映射器
- 支持关系（所有这些）
- 可选（但是理想的）对多个结果集结果的支持
- 不需要任何特殊配置（我只使用数据连接字符串而不使用其他任何东西）
基本上它应该非常轻量级，基本上应该只有一个简单的 Ado.net 包装器和对象映射器。
最重要的要求是：易于使用、得到良好支持并且社区使用它。
I'm not too big of a fan of direct entity mappers, because I still think that SQL queries are fastest and most optimized when written by hand directly on and for the database (using correct joins, groupings, indexes etc).
On my current project I decided to give BLToolkit a try and I'm very pleased with its wrapper around Ado.net and speed so I query database and get strong type C# objects back. I've also written a T4 that generates stored procedure helpers so I don't have to use magic strings when calling stored procedures so all my calls use strong types for parameters.
Basically all my CRUD calls are done via stored procedures, because many of my queries are not simple select statements and especially my creates and updates also return results which is easily done using a stored procedure making just a single call. Anyway...
Downside
The biggest drawback of BLToolkit (I'd like everyone evaluating BLToolkit to know this) aren't its capabilities or speed but its very scarce documentation as well as support or lack thereof. So the biggest problem with this library is doing trial and error to get it working. That's why I also don't want to use too many different parts of it, because the more I use the more problems I have to solve on my own.
Question
What alternatives do I have to BLToolkit that:
- support use of stored procedures that return whatever entities I provide that are not necessarily the same as DB tables
- provide a nice object mapper from data reader to objects
- supports relations (all of them)
- optional (but desirable) support for multiple result-set results
- doesn't need any special configuration (I only use data connection string and nothing else)
Basically it should be very lightweight, should basically just have a simple Ado.net wrapper and object mapper.
And the most important requirement: is easy to use, well supported and community uses it.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
替代方案（2011 年 5 月）
我可以看到大佬已经将他们的访问策略转换为微型 ORM 工具。当我评估 BLToolkit 时，我也抱着同样的想法，因为对于我使用的功能来说，它感觉很庞大（1.5MB）。最后，我决定编写前面提到的 T4（有问题的链接），以使我在调用存储过程时更轻松。但是BLToolkit内部仍然有很多可能性我根本不使用甚至不理解（问题中也指出了原因）。
最好的替代方案是微型 ORM 工具。也许将它们称为“微对象映射器”会更好。他们都有相同的目标：简单和极速。他们没有遵循大型 ORM 的 NoSQL 范式，因此大多数时候我们必须编写（几乎）日常 TSQL 来支持他们的请求。它们获取数据并将其映射到对象（有时还提供更多内容 - 请在下面查看）。
我想指出其中的三个。它们都在单个代码文件中提供，而不是以编译的 DLL 形式提供：
动态(.net 4+)Person+Address）动态类型映射（.net 3.5或更早版本不支持）DynamicModel类，并提供来自任意裸机 TSQL 的 CRUD 功能或映射动态IsNewSqlBuilder类，可以更轻松地构建 TSQL 语句在所有三个中，PetaPoco 似乎在开发方面最活跃，并且通过利用其他两个（以及其他一些）的优点来支持大多数事情。
在这三个网站中，Dapper 拥有最好的实际使用参考，因为它被世界上流量最高的网站之一使用：Stackoverflow。
它们都受到魔术字符串问题的困扰，因为大多数时候您直接将 SQL 查询写入其中。但 T4 可以缓解其中的一些问题，因此您可以进行强类型调用，在 Visual Studio 中动态提供智能感知、编译时检查和重新生成。
动态类型的缺点
我认为动态类型的最大缺点是维护。想象一下您的应用程序使用动态类型。一段时间后查看您自己的代码将变得相当有问题，因为您没有任何具体的类可供观察或坚持。尽管动态类型是一种祝福，但从长远来看，它们也是一种诅咒。
Alternatives (May 2011)
I can see that big guns have converted their access strategies to micro ORM tools. I was playing with the same idea when I evaluated BLToolkit, because it felt bulky (1.5MB) for the functionality I'd use. In the end I decided to write the aforementioned T4 (link in question) to make my life easier when calling stored procedures. But there are still many possibilities inside BLToolkit that I don't use at all or even understand (reasons also pointed out in the question).
Best alternative are micro ORM tools. Maybe it would be better to call them micro object mappers. They all have the same goals: simplicity and extreme speed. They are not following the NoSQL paradigm of their big fellow ORMs, so most of the time we have to write (almost) everyday TSQL to power their requests. They fetch data and map them to objects (and sometimes provide something more - check below).
I would like to point out 3 of them. They're all provided in a single code file and not as a compiled DLL:
IDbConnectionwhich means it supports any backing data store as long there's a connection class that implementsIDbConnectioninterface;dynamic(.net 4+)Person+Address)dynamictype mapping (no support in .net 3.5 or older baby)DynamicModelclass that your entities inherit from and provides CRUD functionaly or maps from arbitrary baremetal TSQLdynamicIsNewSqlBuilderclass for easier building TSQL statementsOf all three PetaPoco seems to be the liveliest in terms of development and support most of the things by taking the best of the other two (and some others).
Of all three Dapper has the best real-world usage reference because it's used by one of the highest traffic sites on the world: Stackoverflow.
They all suffer from magic string problem because you write SQL queries directly into them most of the time. But some of this can be mitigated by T4, so you can have strong typed calls that provide intellisense, compile-time checking and re-generation on the fly within Visual Studio.
Downside of
dynamictypeI think the biggest downside of
dynamictypes is maintenance. Imagine your application using dynamic types. Looking at your own code after a while will become rather problematic, because you don't have any concrete classes to observe or hang on to. As much asdynamictypes are a blessing they're as well a curse on the long run.