业务层外观与混合业务组件 [英] Business Layer Facade vs Mingled Business Components
问题描述
我目前正在为大型应用程序设计基础.我们将采用传统的 3 层系统，在数据层使用 EF，在业务层使用普通 jane c# 类，在 ui 层使用 MVC/WCF.我们已经制作了足够多的应用程序原型，以意识到这对我们有用，但是由于业务需求的复杂性某些业务组件相互交互是很常见的.
I'm currently designing the foundation for a large application. We are going with the traditional 3 tier system using EF in the data layer, plain jane c# classes in the business layer and MVC / WCF for the ui layer. We have prototyped enough of the application to realize that this will work for us, however due to the complexity of the business requirements it will be common for some of the business components interact with one another.
考虑以下两个业务组件:
Consider the following two business components:
- RetailManager - 处理系统中与零售相关的一切
- CartManager - 处理与购物车体验相关的一切
例如，在购买商品的结帐过程中，两者会进行交互.需要减少所购商品的库存.
The two interact, for instance, during the checkout process when an item is purchased. The inventory for the purchased item needs to be reduced.
这是我目前的思考过程:
Here is my thought process so far:
让业务组件相互引用并确保循环引用永远不会发生(CartManager 引用 RetailManager，但绝不会反过来).Checkout"将是 CartManager 类上的一个方法，它将调用 RetailManager 上的一个方法来调整库存.虽然这会奏效，但我不确定它的扩展性如何，以及随着时间的推移维护成本会是多少.我觉得这不是 100%正确".
Let business components reference each other and ensure cyclical references never happen (CartManager references RetailManager, but never the other way). "Checkout" would be a method on the CartManager class, and it would call a method on the RetailManager to adjust inventory. While this will work, I'm not sure how well it will scale, and what the maintenance cost will be over time. It doesn't feel 100% "right" to me.
在业务组件和 UI 层之间创建 Facade.在这个例子中，Facade 将有 checkout 方法和对两个经理的引用.我比第一种更喜欢这种方法，但是我知道并非我的所有业务对象都需要 Facade，而且我不想创建大量 Facade 类只是为了拥有空的传递方法.
Create a Facade between the business components and the UI tier. In this example, the Facade would have the checkout method and a reference to both managers. I like this approach more than the first, however I know that not all of my business objects will need a Facade, and I don't want to create a ton of Facade classes just to have empty pass through methods.
我倾向于 2，但需要注意的是，我只会在需要的地方创建外观类.UI 层将可以访问 Facade 和业务层组件，并且必须知道何时使用哪个(我不喜欢这个解决方案的唯一部分).
I'm leaning towards 2, with the caveat that I will only create facade classes where needed. The UI tier will have access to both the Facade and the business layer components and will have to know when to use which (the only part I don't like about this solution).
我进行了大量研究，但一直无法想出一个感觉完全正确的解决方案.
I've done a lot of research but haven't been able to come to come up with a solution that feels completely right.
欢迎任何关于以这种方式使用外观模式的想法，或其他解决问题的想法.
Any thoughts on using the facade pattern in this way, or other ideas to solve the problem are welcome.
提前致谢.
推荐答案
我倾向于使用外观实现.
I would tend to go with facade implementation.
我首先要问自己，谁有责任在结账时确保减少库存?我认为减少库存不是 CartManager 的责任.我会有第三个类(在您的案例外观中)，以确保每当 CartManager 签出一个项目时，相应的项目就会从库存中减少.
I would first ask myself, whose responsibility is it to make sure that inventory is reduced when a checkout happens? I don't think it is responsibility of CartManager to reduce the inventory. I would have a third class (in your case facade) that makes sure that whenever an item is checked out by CartManager, corresponding item is reduced from inventory.
我会考虑的另一个选择是基于事件的实现.CartManager 会在商品被检出时引发 ItemCheckedOut 事件.RetailManager 将订阅此事件并在引发事件时减少库存.如果您是事件驱动设计的新手，请在 quora 上关注这个问题 - http://www.quora.com/What-are-some-good-resources-on-event-driven-software-design
Another option I would consider is event based implementation. CartManager would raise a ItemCheckedOut event whenever an item is checked out. RetailManager would subscribe to this event and would reduce the inventory whenever an event is raised. If you are new to event driven design, follow this question on quora - http://www.quora.com/What-are-some-good-resources-on-event-driven-software-design
这篇关于业务层外观与混合业务组件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
