Facade 模式中来自 Facade 的调用次数
我们正在“讨论”应该在外观层中放置什么以及外观层应该对底层进行多少次调用。
在我们的项目中，我们有一个协调层来协调对服务和数据库的调用。我们还有一个包含业务规则和计算的业务层。
我们的外观层具有安全检查、日志记录和错误处理功能。
现在的问题是：外观应该只对编排层进行一次调用，还是可以进行多次调用。如果只是一次调用，则应将这些层合并为单个层。
这些是用 C# 编写的 WCF 服务。
We are having a "discussion" about what should be placed in the facade layer and how many calls the facade layer should make to the underlying layers.
In our project we have an Orchestration layer that coordinates calls to services and databases. We also have a business layer with business rules and calculations.
Our facade layer has a security check, logging and error handling.
Now the question: Should the facade have only a single call to the orchestration layer or is it Ok with multiple calls. If it is only a single call should these layers be merged into a single layer.
These are WCF services written in C#.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
只要调用只执行一项操作（在调用者看来）并且完全执行，Facade 内部的调用数量就不重要。
请记住，调用者的单个操作可能包括记录日志、运行业务规则、打开数据库连接、写入数据库，最后关闭并清理连接。
The number of calls inside of the Facade shouldn't matter as long as the call does one single operation (in the eyes of the caller) and does it completely.
Keep in mind that a single operation to the caller may include logging, running business rules, opening a connection to the database, writing to the database, and then finally closing and cleaning up the connection.
我支持贾斯汀的回答，但我只补充一点考虑。如果您的编排层也处理业务层，并且您的外观最终成为编排任务的一对一映射，那么您可以考虑将编排作为您的外观。但在这种情况下，您不会问，所以要么您的外观正在简化编排使用协议，要么编排和业务层是对等的。无论哪种情况，您都需要一个与编排模块不同的外观
I support Justin's answer, to which I add only one consideration. If your orchestration layer does handle business layer too and if your facade ends up being a 1-to-1 map to orchestration tasks, then you could consider having orchestration to be your facade. But in this case you wouldn't be asking, so either your facade is simplifying the orchestration usage protocol, or orchestration and business layer are peers. In either case you need a facade that is distinct from orchestration module
Facade 层和 Orchestration 层是松散耦合的吗？如果是这样，那么我的答案是“不”，不要合并。仅从原则的角度来看，我认为松散耦合是有价值的，并且应该保留它。
当它进行多个调用时，它正在执行的操作与编排层正在执行的操作之间有什么区别？想想他们活着的理由。
但是，我允许区分纯粹的“业务”调用和“跨领域”调用。通过建立只允许一个“业务”调用“通过”外观的约定，您可以保持业务服务的干净结构（永远不会出现任何混乱）；但另一方面，您在技术上不受限制进行其他增强系统行为和功能的交叉调用。
Are the Facade and Orchestration layers loosely-coupled? If so then my answer would be "no" don't merge. Just from a principles perspective I would think there is value in the loose-coupling, and that it should be preserved.
The moment it makes more than one call - what's the difference between what it's doing and what the Orchestration layer is doing. Think about their reason for living.
However, I'd allow a distinction between purely "business" calls and "cross-cutting" calls. By establishing the convention that only one "business" call is allowed to be "passed through" the Facade you keep a clean structure to the business services (there's never any confusion); but on the other hand your not technically constrained from making other cross cutting calls that augment system behavior and capability.