问题描述
由于我正在处理一个比较复杂的问题，我想使用域驱动设计方法来解决这个问题。问题在于计算客户的月度发票。目前的解决方案是作为一个很长的存储过程实现的，难以维护。
Since I am working on a relatively complex problem, I would like to use the Domain Driven Design approach to solving it. Problem in question is calculating monthly invoices for clients. The current solution is implemented as a very long Stored Procedure that is difficult to maintain.
我想使用面向对象的环境（可能是POCO和实体框架），但我是担心表现。当前SP需要大约10分钟才能通过使用设置操作生成超过30万条记录。我认为这将非常难以实现与任何ORM，因为它会一个一个加载实体，并以相同的方式发送更新。 （以前的版本一个个访问记录需要5个小时。）
I would like to use Object Oriented environment (possibly POCO and Entity Framework) but I am worried about performance. Current SP takes some 10 minutes to generate more than 300 000 records by using set operations. I think this would be very difficult to achieve with any ORM since it will load entity one by one and send updates in the same manner. (Previous version took 5 hours when accessing records one by one.)
如何为大规模操作创建丰富的模型？
How would you create a rich model for massive operations?
推荐答案
在应用富域模型时，我尽量避免使用大规模的操作。
I avoid using massive operations as possible as I can when applying rich domain model.
批次可以替换为事件。例如，我需要一个每日订单计数报告。
Some batch could be replaced with events. For example, I need a daily order count report.
批处理解决方案：
在一天结束时触发的调度任务从今天发出的订单收集数据。
A scheduling task which is triggered at the end of the day collects data from orders placed today.
或使用事件
当放置新订单时，PlaceOrderService发布OrderPlacedEvent。一个eventHandler收到该事件并插入到T_ORDER_COUNT_ENTRY
The PlaceOrderService publishes a OrderPlacedEvent when a new order is placed. And a eventHandler receives the event and inserts to T_ORDER_COUNT_ENTRY
|TODAY |ORDER_ID|
|2012-04-01|123 |
|2012-04-01|124 |
我们可以使用SQL count（）来计算每日订单数量报告。
The we could use SQL count() to calculate the daily order count report.
某些其他批次可以并行运行。例如，如果在30分钟内未支付，我的订单将自动取消。
Some other batch could run parallelly. For example, My orders should be canceled automatically if unpaid in 30 mins.
原始批处理解决方案是逐个获取所有订单并调用其cancel（）。
The original batch solution is fetch all orders satisfied one by one and invokes their cancel().
当前解决方案是逐个获取所有订单，发送一个OrderIsOverdue消息。消息处理程序收到包含orderId的消息，并检索该订单然后取消。
The current solution is fetch all orders satisfied one by one and sends a OrderIsOverdue message. Message handlers receive the message containing an orderId and retrieve the order then cancel.
如果取消操作比发送消息花费的时间更长，我认为这很有用。如果硬件资源负担得起，可以添加更多的消息处理程序来提高吞吐量。
I think this is useful when the cancel operation takes far more time than sends a message . More message handler could be added to improve the thoughput if the hardware resources can afford it.
这篇关于如何使用丰富的域名进行大规模的操作？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！