java命名来自项目_您在Java项目中使用什么策略进行包命名？...

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

还有一些额外的规则：

>层从最常见(底部)到最具体(顶部)堆叠

>每个层都有一个公共接口(抽象)

>一个层只能依赖于另一个层的公共接口(封装)

>一个图层只能依赖于更一般的图层(从上到下的依赖关系)

>层优选地取决于其正下方的层

因此,对于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.

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