业务层外观与混合业务组件

Question

我目前正在为一个大型应用程序设计基础。我们将使用传统的 3 层系统，在数据层使用 EF，在业务层使用纯 jane c# 类，在 ui 层使用 MVC/WCF。我们已经对应用程序进行了足够多的原型设计，以意识到这对我们有用，但是由于业务需求的复杂性某些业务组件之间的交互很常见。

考虑以下两个业务组件：

• RetailManager - 处理系统中与零售相关的一切
• CartManager - 处理与购物车体验相关的一切

例如，在购买商品时的结账过程中，两者会进行交互。所购商品的库存需要减少。

到目前为止，这是我的思考过程：

1. 让业务组件相互引用并确保循环引用永远不会发生（CartManager 引用 RetailManager，但绝不会反过来）。 “Checkout”是 CartManager 类的一个方法，它会调用 RetailManager 的一个方法来调整库存。虽然这会起作用，但我不确定它的扩展性如何，以及随着时间的推移维护成本会是多少。我觉得这不是 100%“正确”的。

2. 在业务组件和 UI 层之间创建一个外观。在本例中，Facade 将具有 checkout 方法和对两个管理器的引用。我比第一种方法更喜欢这种方法，但是我知道并不是我的所有业务对象都需要 Facade，而且我不想创建大量的 Facade 类只是为了有空的传递方法。

我倾向于 2，但需要注意的是，我只会在需要的地方创建外观类。 UI 层将可以访问 Facade 和业务层组件，并且必须知道何时使用哪个（我不喜欢这个解决方案的唯一部分）。

我进行了大量研究，但未能提出一个感觉完全正确的解决方案。

欢迎任何关于以这种方式使用外观模式的想法，或其他解决问题的想法。

提前致谢。

Answer 1

这是使用管理器/服务类的典型问题。他们总是容易臃肿。当你达到这一点时，最好开始使用命令。

使用 IoC 的好处是，您不必直接重构所有代码，但可以在有时间时进行。只需开始为所有新功能编写命令，同时为其他一切保留旧架构。

这里是命令介绍：http://blog.gauffin.org/2012/10/writing-decoupled-and-scalable-applications-2/

还有我自己的框架的介绍：http://blog.gauffin.org/2012/10/introducing-griffin-decoupled/

Answer 2

我倾向于使用外观实现。

我首先会问自己，在结账时确保减少库存是谁的责任？我认为减少库存不是CartManager 的责任。我将有第三类（在您的情况下为外观），以确保每当CartManager 签出一个项目时，相应的项目就会从库存中减少。

我会考虑的另一个选择是基于事件的实现。每当签出项目时，CartManager 将引发 ItemCheckedOut 事件。 RetailManager 将订阅此事件，并在引发事件时减少库存。如果您是事件驱动设计的新手，请在 quora 上关注此问题 - http://www.quora.com/What-are-some-good-resources-on-event-driven-software-design

Answer 3

我个人喜欢CQRS的模式，它与其他架构模式自然契合 比如Event Sourcing，适合复杂的域。