命名空间规范.docVIP

命名空间规范 我们设计的主体对象都是业务组件。一切都是围绕业务组件出发，设计其实体、服务接口、操作等。关于业务组件的界定：业务组件是界定实体或功能的边界，在开发中严格禁止跨越业务组件边界操作实体，除非这个访问完全与业务组件的业务逻辑没有关系，如一些汇总报表。否则系统的业务权限规则是无法保证的！ 因此，从模块的角度上看，其命名空间的划分如下图所示： 从整个模块的角度看，包是按照业务组件的名字进行组织的。如果业务组件有具体的有意义的名字，则采用这个名字作为业务组件的包名。 从整个模块的角度看，会有一个公共的工具包。里面的代码为整个模块所使用。从整个模块的角度看，我们还会使用别的模块的业务组件的服务。 引用其他模块的组件服务 包名 说明 nc.impl.模块.reference.模块 其他模块提供给本模块的服务器端服务组件 nc.ui.模块.reference.模块 其他模块提供给本模块的UI服务组件 PUB工具包 包名 说明 nc.impl.模块.pub 服务器端整个模块公共代码工具包 nc.ui.模块.pub UI端整个模块公共代码工具包 nc.vo.模块.pub 跨服务器端、UI端整个模块公共代码工具包 从业务组件的角度看，其由各个技术组件组成。 在业务组件之下，由于包的划分不同，还会存在不同的技术组件。在技术组件之间，一定要注意不能有循环依赖。例如，我们将服务接口和服务实现组件划分为两个类型的的组件，其目的就是要避免循环依赖 循环依赖 打破循环依赖 业务组件命名空间的划分如下图所示： 实体组件：其对应的就是VO类。 UI组件：既有当前实体的维护界面，也有提给本模块或其他模块别的组件的UI界面（例如转单界面）。一个业务组件可能有多个节点来进行处理，因此它也对应多个业务组件视图。 服务组件：既有给其他业务组件提供的服务接口，也有对外暴露的公共服务接口（并不是提供给某个特定组件的服务接口） 服务实现组件：服务组件中接口的实现 操作组件：业务组件的维护、管理操作接口。例如单据的增删改查。此类接口不能被别的业务组件所调用，只能被业务组件自身的UI技术组件所调用 操作实现组件： 操作组件中的接口的实现类 具体命名如下： 实体组件 包名 说明 nc.vo.模块.业务组件.entity 本业务组件的VO和元数据定义类、以及枚举类型 操作组件 包名 说明 nc.itf.模块.业务组件 给前台维护界面提供的操作接口 nc.impl.模块.业务组件.action 给前台维护界面提供的操作接口的实现类 服务组件 包名 说明 nc.pubitf.模块.业务组件.pub 通用服务，任何模块的任何组件都可使用 nc.pubitf.模块.业务组件.模块 针对某个组件提供的特定服务 nc.impl.模块. 业务组件.service.pub 通用服务的实现 nc.impl.模块. 业务组件.service.模块 特定服务的实现 UI组件 包名 说明 nc.ui.模块. 业务组件.editor 编辑事件响应类 nc.ui.模块. 业务组件.action 按钮事件响应类 nc.ui.模块. 业务组件.view 视图 nc.ui.模块. 业务组件.model 模型 nc.ui.模块. 业务组件.service.模块 提供给某个特定组件的UI组件服务 红色部分可选 如果当前组件只有一个视图，则不需要视图名字这一层 BP组件 包名 说明 nc.impl.模块.业务组件.bp Bp的实现类，组合了业务规则