1

这个问题是关于建筑/设计的：

我有一个消费者需要执行 x 个任务，我什么时候应该考虑将消费者分解为更小的任务和/或将更小的任务添加到他们自己的消费者中？

例子：

消费者 FooBarShipping 确实

  • 添加用于报告的数据库条目
  • 为帐户添加数据库条目
  • 添加用于运输的数据库条目
  • 生成运输发票（PDF 或其他格式，如果需要）
  • 创建发货通知
  • 为帐户创建通知

所以我的问题是，我什么时候将要点分解为较小的消费者？消费者运行良好，但我觉得它变得太大，需要重构为更小、更易于管理的流程。

每个要点都应该是它自己的消费者吗？我可以看到将它们分成三个消费者

  • 数据库
  • pdf ( 文件 )
  • 通知

但是消费者应该做的最小工作单元是什么？我真的需要消费者来运行 sql 语句吗？

我看了

对我来说，消费者希望完成基本任务，从而启动其他基本任务。

4

1 回答 1

1

对于一般架构，您有六个模块，每个模块都希望分为：

  • 1 添加用于报告的数据库条目
  • 1 为帐户添加数据库条目
  • 1 为发货添加数据库条目
  • 2 生成运输发票（PDF 或其他格式，如果需要）
  • 3 创建发货通知
  • 3 为帐户创建通知

如果您实现存储库模式，组 1 应分为 3 个存储库。每个存储库处理每个实体（报告、帐户、运输）；但可以提供插入、更新、删除和选择操作。

与第 3 组相同，我不认为通用通知对象（我的术语中的类）是一件好事，因为它可以成长为 x、y、z 实体通知。

但别担心，你已经走在正确的道路上了。如果我谈论依赖，构造函数注入，最好将其分离为 3 个对象。FooBarShipping ship 方法的总体思路：

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.Notify 相同的想法：

InvoiceNotification.Notify(Invoice inv){
    shippingNotification.Notify(inv);
    accoountNotification.Notify(inv);
}

不过，它可能需要针对您的数据结构和实现进行调整。但这是一般的想法。您也可以参考这篇文章（重构为聚合服务）作为参考。

于 2013-05-15T12:39:04.340 回答