DDD 报告场景
我正在尝试创建一个使用 MVC3、EF 和 DDD 方法的报告/分析 Web 应用程序。我很难为现有数据库上的聚合表提供实体或对象类。例如，我将 Orders 和 OrderLine 作为聚合，将 Customers 作为实体。这三个对象可以使用 DDD 方法进行建模，但是如果我想要一个 OrdersAggregate 表，其中包含客户姓名、付款类型等所有详细信息，该怎么办？
我应该在此处创建一个包含客户名称、付款类型属性的对象类吗？等等或者让EF创建他的sql查询并连接相关表？我担心这里的性能，这将部署在云上，并且等待着大量的交易。
有什么建议吗？
I'm trying to create a reporting/analysis web app that will use MVC3, EF and DDD approach. I'm havign a hard time to come up with entities or object classes for aggregated tables on existing database. For example, I have Orders and OrderLine as an aggregate and Customers as Entity. This three objects can be modeled using DDD approach but what if I want to have an OrdersAggregate Table which will contatins all the details like customer name, payment type, etc.
Should I create an object class here which contain the properties of customername, payment type, etc. or let EF create his sql query and join related tables? I'm worrying about performance here and this will be deploed on a cloud and a huge volume of transactions awaits.
Any suggestions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您可以利用 CQRS 和 此处 在某些方面可以利用将读取模型与写入模型分开的好处。
不必实现整个架构，只需将读取与写入模型和服务分开，这使得读取模型可以平直地发送定制的 DTO 以用于评分和分析目的，另一方面在写入模型中可以发送强大的域模型以进行业务逻辑处理。
检查这个和这个示例
You can utilize CQRS and here in some aspects to take the benefit of separating read model from write.
Dont have to implement the entire architecture, just separate the read from write model and services, this make the read model send customized DTOs flat for rading and analysis purposes, and a strong domain model on the other hand in the write model for business logic handling.
check this and this example
我的经验是 DDD 不适合做报告、统计等。
吉米·尼尔森 (Jimmy Nilsson) 等专家告诉您可以使用常规数据访问绕过您的域。
如果你仔细想想，数据的呈现并没有太多的领域逻辑。仅仅为了查看数据而使用 ORM、存储库、聚合根等进行分层和 DDD 风格似乎是一种开销。
只是个人意见。
/祝你好运，最诚挚的问候马格努斯
My experience is that DDD is not suitable for doing reporting, statistics etc.
Some experts in like Jimmy Nilsson tells you to bypass your domain with regular dataacces.
If you just think about it, there is not much domain logic in presenting the data. It just seems like an overhead in doing layers and DDD style with ORM, repositories, aggregateroots etc just for view data.
Just a personal opinion.
/Good Luck and best regards Magnus
我的建议是为此目的创建一个 DTO 类，并使用从 SQL 命令（手工制作）返回的数据集填充连接和关系。
只是一个建议，因为我用这种方法解决了类似的问题。
My suggestion is to create a DTO class for this purpose, and fill using a dataset returned from a SQL command (hand-made) with your joins and relationships.
Is only a suggestion, because I used this approach to a similar problem.