查询/报告层设计问题（DDD/CQRS）
我正在考虑如何为我的应用程序构建查询/读取层，我认为我要做的是创建数据库视图来展平模型并使用实体框架进行数据访问。
我的问题是，我是否应该允许我的控制器直接访问我的 IQueryContext，它本质上只是抽象 EF 上下文。或者我应该创建一个事务脚本样式的查询服务，例如包含所有相关报告方法的 ICustomerQueries？或者也许每个查询都是它自己的概念并且存在于它自己的对象中，即； GetProductsByCustomerQuery
任何帮助/想法/参数都会很棒！
i'm thinking about how i would like to structure my query/read layer for my application and i think what i am going to do is create database views to flatten out the model and use entity framework for my data access.
my question is, should i just allow my controllers direct access to my IQueryContext, which is just essentially abstracting the EF context. or should i create a transaction script style query service, like ICustomerQueries that contains all the related reporting methods? or maybe each query is its own concept and lives in its own object ie; GetProductsByCustomerQuery
any help/ideas/arguments would be great!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我会让查询端尽可能简单。我可能会因此而受到批评，但在我看来，尽可能接近原始 SQL，在某些情况下甚至到
SELECT * FROM ...可能就足够了。因此：通过 EF 或 Linq2SQL 公开您的扁平化视图，以及后来的非规范化表，并将它们绑定到您的 UI（此时我什至会质疑是否需要 ORM）。不需要进一步的抽象层。节省时间专注于核心领域。
I'd keep the query side as simple as possible. I'll probably get flamed for this, but in my opinion getting as close to raw SQL as you can, in some cases even down to
SELECT * FROM ..., might suffice.Thus: Expose your flattened out views -- and later your denormalized tables -- via EF or Linq2SQL, and bind them to your UI (I'd even go as far and question the need of an ORM at this point). No further abstraction layers required. Saves time to focus on the Core Domain.
我倾向于在查询端使用 WCF 数据服务。因此，我有一个读取数据库的实体框架模型，然后在其之上创建一个 WCF 数据服务（只需几分钟），然后查询该 WCF 数据服务。
它很简单，它是一致的，您可以将其配置为只读访问，它支持 LINQ 甚至 OData 协议，以便您可以在 URL 中编写查询。
另请参阅：
I tend to use WCF Data Services on the query side. So, I have an Entity Framework model of the Read database, then create a WCF Data Service on top of that (that only takes a few minutes), then query that WCF Data Service.
It's easy, it's consistent, you can configure it for read-only access, it supports LINQ and even the OData protocol, so that you can write queries in your URL.
See also: