您在Java项目中使用什么策略进行包命名？为什么？

发布时间：2020-12-15 07:36:25 所属栏目：Java 来源：网络整理

导读：我刚才考虑过这个问题,最近我的商店正在制作它的第一个真正的 Java网络应用程序. 作为介绍,我看到两个主要的包命名策略. (要清楚,我不是指整个’domain.company.project’的一部分,我在谈论它下面的包约定.)无论如何,我看到的包命名约定如下：功能：根据业

我刚才考虑过这个问题,最近我的商店正在制作它的第一个真正的 Java网络应用程序.

作为介绍,我看到两个主要的包命名策略. (要清楚,我不是指整个’domain.company.project’的一部分,我在谈论它下面的包约定.)无论如何,我看到的包命名约定如下：

>功能：根据业务领域,根据其功能在架构上命名您的包,而不是其身份.另一个术语可能是根据’layer’命名.所以,你有一个* .ui包和一个* .domain包和一个* .orm包.您的包是水平切片而不是垂直切片.

这比逻辑命名更常见.事实上,我不相信我曾经见过或听说过这样做的项目.这当然让我很害羞(有点像认为你已经想出了NP问题的解决方案),因为我不是非常聪明,我认为每个人都必须有充分的理由按照他们的方式去做.另一方面,我并不反对人们只是错过了房间里的大象,而且我从来没有听到过以这种方式进行包装命名的实际论点.它似乎是事实上的标准.
>逻辑：根据业务域标识命名您的包,并将与该垂直功能片有关的每个类放入该包中.

正如我之前提到的,我从未见过或听说过这一点,但这对我来说很有意义.

>我倾向于垂直接近系统而不是水平接近系统.我想进入并开发订单处理系统,而不是数据访问层.显然,我很有可能在该系统的开发中触及数据访问层,但重点是我不这么认为.当然,这意味着当我收到变更单或者想要实现一些新功能时,不必为了找到所有相关的类而不必在一堆包中钓鱼.相反,我只是查看X包,因为我正在做的与X有关.
>从开发的角度来看,我认为让您的软件包记录您的业务领域而不是您的架构是一项重大胜利.我觉得这个领域几乎总是系统的一部分,因为系统的体系结构,特别是在这一点上,它的实现几乎变得平凡,因此很难理解.事实上,我可以通过这种类型的命名约定进入系统,并立即从包的命名知道它处理订单,客户,企业,产品等,这似乎非常方便.
>看起来这样可以让您更好地利用Java的访问修饰符.这使您可以更清晰地将接口定义到子系统中,而不是定义到系统的各个层中.因此,如果你有一个你想要透明持久的订单子系统,理论上你永远不会让任何其他东西知道它是持久的,因为不必在dao层中为其持久性类创建公共接口,而是将dao类包装在只有它处理的类.显然,如果您想公开此功能,可以为其提供界面或将其公开.通过将系统功能的垂直切片分成多个包,您似乎失去了很多.
>我认为我可以看到的一个缺点是,它确实使得剥离层变得更加困难.您必须进入并更改所有软件包中的所有类,而不是仅删除或重命名软件包,然后使用备用技术删除新软件包.但是,我不认为这是一个大问题.这可能源于缺乏经验,但我必须想象,与您进入和编辑系统中的垂直特征切片的次数相比,您更换技术的次数相形见绌.

所以我想那个问题会告诉你,你如何命名你的包裹以及为什么？请理解我并不一定认为我偶然发现了金鹅或其他东西.我对这一切都很陌生,主要是学术经历.但是,我无法发现我的推理中的漏洞,所以我希望你们都能这样,以便我能继续前进.

解决方法

对于包装设计,我首先按层,然后通过一些其他功能.

还有一些额外的规则：

>层从最常见(底部)到最具体(顶部)堆叠
>每个层都有一个公共接口(抽象)
>一个层只能依赖于另一个层的公共接口(封装)
>一个图层只能依赖于更一般的图层(从上到下的依赖关系)
>层优选地取决于其正下方的层

因此,对于Web应用程序,您可以在应用程序层中具有以下层(从上到下)：

>表示层：生成将在客户端层中显示的UI
> application layer：包含特定于应用程序的逻辑,有状态
>服务层：按域分组功能,无状态
>集成层：提供对后端层的访问(db,jms,email,…)

对于生成的包布局,这些是一些额外的规则：

>每个包名的根目录是< prefix.company>.< appname>.< layer>
>层的界面进一步按功能划分：< root>.< logic>
>图层的私有实现以private：< root> .private为前缀

这是一个示例布局.

表示层由视图技术划分,并且可选地由(组)应用划分.

com.company.appname.presentation.internal
com.company.appname.presentation.springmvc.product
com.company.appname.presentation.servlet
...

应用程序层分为用例.

com.company.appname.application.lookupproduct
com.company.appname.application.internal.lookupproduct
com.company.appname.application.editclient
com.company.appname.application.internal.editclient
...

服务层分为业务域,受后端层中的域逻辑的影响.

com.company.appname.service.clientservice
com.company.appname.service.internal.jmsclientservice
com.company.appname.service.internal.xmlclientservice
com.company.appname.service.productservice
...

集成层分为“技术”和访问对象.

com.company.appname.integration.jmsgateway
com.company.appname.integration.internal.mqjmsgateway
com.company.appname.integration.productdao
com.company.appname.integration.internal.dbproductdao
com.company.appname.integration.internal.mockproductdao
...

分离这样的软件包的优点是管理复杂性更容易,并且提高了可测试性和可重用性.虽然看起来很多开销,但根据我的经验,它实际上非常自然,每个人都在这个结构(或类似的)上工作,在几天内就可以完成.

为什么我认为垂直方法不是那么好？

在分层模型中,几个不同的高级模块可以使用相同的低级模块.例如：您可以为同一个应用程序构建多个视图,多个应用程序可以使用相同的服务,多个服务可以使用相同的网关.这里的技巧是,当在层中移动时,功能级别会发生变化.更具体层中的模块不会在更一般的层上映射模块上的1-1,因为它们表达的功能级别不映射1-1.

当您使用垂直方法进行包装设计时,即首先按功能划分,然后将具有不同功能级别的所有构建块强制插入到相同的“功能夹克”中.您可以为更具体的模块设计通用模块.但是这违反了更普遍的层不应该知道更具体的层的重要原则.例如,服务层不应该在应用层的概念之后建模.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!