业务层门面与明确的业务组件

Question

我目前正在为大型应用程序设计基础。我们将使用传统的3层系统，在数据层中使用EF，在业务层使用简单的jane c＃类，在ui层使用MVC / WCF。我们有足够的应用程序原型来实现这对我们有用，但是由于业务需求的复杂性，一些业务组件相互交互将是常见的。

考虑以下两个业务组件：

• RetailManager - 处理与系统零售相关的所有事项
• CartManager - 处理与购物车体验相关的所有内容

例如，在购买商品的结账过程中，这两者相互作用。需要减少购买物品的库存。

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

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

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

   < / LI>

   我倾向于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并且适用于复杂的域。