0

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

考虑以下两个业务组件：

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

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

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

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

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

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

我做了很多研究，但还没有想出一个感觉完全正确的解决方案。

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

提前致谢。

4

3 回答 3

2

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

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

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

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

于 2012-11-09T12:26:46.547 回答
1

我倾向于使用外观实现。

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

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

于 2012-11-07T21:35:21.103 回答
0

我个人喜欢CQRS的模式，它自然地适合其他架构模式，例如事件溯源，并且适合复杂的领域。

于 2012-11-08T13:48:24.530 回答