这个问题是关于建筑/设计的:
我有一个需要执行x个任务的消费者，我什么时候应该考虑将消费者分解成更小的任务和/或将更小的任务添加到他们自己的消费者中?
的例子:
Consumer FooBarShipping does
- 为报告 添加数据库条目
- 为帐户 添加数据库条目
- 为航运添加数据库条目
- 生成运输发票(PDF或其他格式，如果需要)
- 创建装运通知
- 为帐户 创建通知
所以我的问题是，我什么时候把要点分解成更小的消费者?消费者运行得很好，但我觉得它变得太大了，需要重构成更小、更易于管理的进程。
每个要点应该是它自己的消费者吗?我可以把他们分成三个消费者
- 数据库
- pdf (documents)
但是，消费者应该做的最小工作单位是什么?我真的需要一个消费者来运行sql语句吗?
I watched
- https://www.youtube.com/watch?feature=player_embedded& v = E708csv4XgY
，对我来说，消费者希望做一些基本的任务，这些任务会启动其他的基本任务。
对于一般架构，您有六个模块，每个模块都希望分组为:
- 1为报告 添加数据库条目
- 1为帐户 添加数据库条目
- 1为shipping添加数据库条目
- 2生成运输发票(PDF或其他格式，如果需要)
- 3创建装运通知
- 3为帐户 创建通知
如果您实现存储库模式，则应该将组1划分为3个存储库。每个仓库处理每个实体(报告、账户、发货);但可提供插入、更新、删除和选择操作。
与第3组相同，我不认为一般通知对象(在我的术语中是类)是一件好事，因为它可以成长为x, y, z实体通知。
但是别担心，你已经在正确的道路上了。如果我谈论依赖，构造函数注入，最好将其分离为3个对象。FooBarShipping方法的总体思路:FooBarShipping.Ship(Invoice inv){
invoiceRepository.InsertNew(inv);
invoiceGenerator.GenerateInvoice(inv);
invoiceNotification.Notify(inv);
}
以及InvoiceRepository的总体思路。InsertNew:
InvoiceRepository.InsertNew(Invoice inv){
reportingRepository.InsertNew(inv.Reporting);
accountRepository.InsertNew(inv.Account);
shippingRepository.InsertNew(inv.Shipping);
}
与InvoiceNotification相同。通知:
InvoiceNotification.Notify(Invoice inv){
shippingNotification.Notify(inv);
accoountNotification.Notify(inv);
}
可能需要根据你的数据结构和实现进行调整。但这是总体思路。您也可以参考这篇文章(重构聚合服务)。