一尘不染

按功能打包方法好吗?

spring

我喜欢按功能打包的想法,它极大地减少了在编码时跨包移动的时间,并且所有相关的东西都放在一个地方(包)。但是,不同包中的服务之间的交互又如何呢?

假设我们正在构建一个博客应用程序,并且将所有与用户相关的操作(控制器/服务/存储库)放入com.mycompany.myblog.users程序包中。以及所有与博客帖子相关的操作(控制器/服务/存储库)com.mycompany.myblog.posts。

现在,我想显示用户个人资料以及他发布的所有帖子。我应该打电话myblog.posts.PostsService.getPostsByUser(userId)myblog.users.UserController.showUserProfile()吗?

封装之间的耦合又如何呢?

同样,无论我在何处阅读按功能打包,每个人都说这是一个好习惯。那么,为什么许多书作家甚至框架鼓励按层次分组?只是想知道:


阅读 311

收藏
2020-04-16

共1个答案

一尘不染

应该将一起重用的类打包在一起,以便可以将打包程序视为可供你使用的完整产品。一起重用的那些应该与那些不重用的那些分开。例如,你的Logging实用程序类不必与文件io类一起使用。因此,将所有日志记录分别打包。但是日志记录类可能彼此相关。因此,请创建一种用于日志记录的完整产品,例如,想要一个更好的名称commons-logging,将其包装在一个(可重用的)jar中,并创建另一个单独的完整产品用于io实用程序,再一次是为了获得更好的名称,例如commons- io.jar。如果将“ commons-io”库更新为“支持java nio”,则你不一定要对日志记录库进行任何更改。因此将它们分开会更好。

现在,假设你希望你的日志记录实用程序类支持结构化日志记录,以便通过诸如splunk之类的工具进行某种日志分析。你的日志记录实用程序的某些客户端可能想要更新到较新的版本;其他一些可能不会。因此,当你发布新版本时,请将所有需要的类打包并一起重新使用以进行迁移。因此,实用程序类的某些客户端可以安全地删除旧的commons-logging jar并转移到commons-logging-new jar。其他一些客户仍然可以使用较旧的jar。但是,不需要客户同时拥有这两个jar(新的和旧的),这仅仅是因为你强迫他们为旧的打包jar使用某些类。

避免循环依赖。a依赖b; b对c 条件; 但是d取决于a。该场景显然令人望而却步,因为很难定义层或模块等,并且你不能相对于彼此独立地进行更改。

同样,你可以打包你的类,以使如果某个层或模块发生更改,则不必一定更改其他一个或多个模块。因此,例如,如果你决定从旧的MVC框架升级到其余的API,则仅视图和控制器可能需要更改。你的模型没有。

2020-04-16