在 CQRS 中使用 MicroORM 读取层
各位， 我正在考虑使用 microORM（例如 Dapper.net）作为 CQRS 应用程序（Asp.Net MVC）的读取访问组件，并使用实体框架来操作域。
这是 CQRS 轻量级，我没有使用事件源等。我已经多次看到它提到 CQRS 中的只读模型应该是轻量/简单的，可以查询数据层，可以使用 ADO.net 之类的东西 这意味着我们的代码或某些 XML 文件中可能会硬编码 SQL 查询字符串。当我们必须在一侧维护域映射并在另一侧维护 SQL 语句时，我应该如何证明这种方法的合理性？
有人以这种方式在 CQRS 解决方案中使用 MicroORM 吗？ 谢谢 米克
Folks,
Im considering using a microORM such as Dapper.net for the read access component of a CQRS application (Asp.Net MVC), with Entity Framework being used for manipulating the domain.
This is CQRS light, I am not using event sourcing etc. I have seen it mentioned several times that the read only model in CQRS should be light/simpleas possible querying the data layer, possible using something like ADO.net
That implies potentially hardcoding SQL Query strings in our code or in some XML file. How should I go about justifying this approach where we have to maintain the domain mappings on one side and SQL statements on another?
Has anyone used MicroORM's in a CQRS solution in this way?
Thanks
Mick
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，您绝对可以使用 Dapper、PetaPoco、Massive、Simple.Data 或您想要的任何其他微型 ORM。过去我们使用 NHibernate 来解决这个问题，但它的重量是 10,000 磅。大猩猩与我们需要的相比。
在我们对这些库的评估中，我们真正喜欢 Simple.Data 和 Petapoco 的一件事是，它们每个都可以使您的查询适应不同的数据库引擎（包括 Mongo），而只需进行最少的调整，而 Dapper 基本上是一大堆 SQL 字符串 - -它是“字符串类型”。不要误会我的意思，Dapper 很棒，非常非常快，而且绝对会很好用。只需在提交之前评估您的功能和非功能需求。
以下是使用 NuGet 对每个主要微型 ORM 进行下载的相对数量（截至 2012 年 1 月 1 日左右）。对于我们来说，拥有一个拥有大量下载的良好社区始终是必须的，以便在出现问题时帮助解决问题：
最后，您可能想要调查的一件事是您的推理完全落后于 SQL 的读取模型。如果您的域正在发布事件（无论事件来源如何），并且您正在写入简单、平面/非关系视图模型，那么您可能能够摆脱像推送到浏览器的 JSON 文件这样简单的事情然后浏览器会解释并使用它来填充您的 HTML 模板。有各种可用的选项，您只需确定最适合您的场景的选项即可。
Yes, absolutely you can use Dapper, PetaPoco, Massive, Simple.Data, or any other micro ORM you would like. In the past we have used NHibernate to solve the problem but it was a 10,000 lbs. gorilla compared to what we needed.
One thing that we really liked about Simple.Data and Petapoco in our evaluation of those libraries was that they each could adapt your queries to different database engines (including Mongo) with minimal tweaking necessary, whereas Dapper was basically one big bunch of SQL strings--it was "stringly typed". Don't get me wrong, Dapper's great and is very, very fast and will absolutely work great. Just evaluate your functional and non-functional requirements before committing.
Here are the relative number of downloads using NuGet for each of the primary micro ORMs (as of about 1/1/2012). For us, having a good community with lots of downloads is always a must in order to help iron out issues when the arise:
Lastly, one thing you may want to investigate is your reasoning behind SQL altogether for your read models. If your domain is publishing events (regardless of event sourcing), and you're writing to simple, flat/non-relational view models, you may be able to get away with something as simple as JSON files that are pushed to the browser which the browser then interprets and uses to populate your HTML templates. There's all kinds of options that are available, you just need to determine what works best in your scenario.