服务层模式 - 我们可以避免特定情况下的服务层吗?

时间:2010-04-08 22:00:18

标签: design-patterns

我们正在尝试使用服务层模式实现一个应用程序,因为我们的应用程序也需要连接到其他多个应用程序,并在网上搜索,我们发现这个链接的示例图形为“正确”的应用方式图案:

martinfowler.com - Service Layer Pattern

但现在我们有一个问题:如果我们的系统需要实现某些业务逻辑,仅针对我们不需要与其他系统共享的应用程序(如系统本身的某些维护数据)。基于此图:

Service Layer Patter by matinfowler

看起来,为此实现服务层是不必要的;避免服务层更加实用,只需从用户界面转到业务层(例如)。在这种情况下,实施服务层模式的正确方法是什么?对于我告诉你的场景,你有什么建议我们?

提前致谢。

2 个答案:

答案 0 :(得分:9)

“服务层”只是对域逻辑的抽象。抽象可以是任何程度的,包括透明的。

术语层有误导性。我认为Martin本人会同意它更好地称为上下文边界(来自域驱动设计)。这意味着您可以拥有许多服务层,以不同程度抽象您的域。您向UI公开的服务“图层”API可以在您的域中执行比您向集成网关公开的服务图层更多的内容。

我建议按功能轮廓分解这些服务块。 (例如,用于批量导入数据的一组服务和用户正常交互的一组服务应该几乎完全分开。)这样,如果您需要将API公开给您希望与您交互的另一个应用程序与用户可以使用的用户完全相同的方式使用与UI相同的API。

答案 1 :(得分:1)

如您发布的链接中所述,服务层通过封装(复杂)业务逻辑和集中涉及多个资源的事务控制来为客户端定义“接口”。服务层不仅在您需要“共享”服务时使用,它只是使它更容易。但即使只有一个消费者,集中控制交易也是有道理的。