项目结构及项目对象-CSDN博客

2019独角兽企业重金招聘Python工程师标准>>>

我按自己的理解重新定义系统用户对象（访客、会员、管理员 ....）、用户功能操作、业务处理对象、数据对象、数据访问对象。期望能按java的面向对象思想用对象定义的方式重新规划项目。并能与spring、strust 等流行框架不冲突。

总体思路为：用户向系统发送操作指令，系统针对用户操作执行对应业务处理流程。业务处理流程中产生数据对象，最终业务处理流程使用数据访问对象对数据对象执行CRUD操作。

系统核心对象：用户对象（UserObject），业务处理对象（Business Objects），数据对象（Data Object），数据访问对象（Data Access Object）。

优点：用户对象与数据对象分离，摆脱对象定义的混乱。比如我们系统中经常用到 Member 对象，会定义 MemberBO，MemberDAO 等等。然后里面写一堆方法，MemberBO中放与member 相关的业务处理方法，MemberDAO中放与member表相关的CRUD方法。可是，这个Member 到底是一个用户，还是一张数据表呢？好像都可以又好像都不可以。比如会员下订单操作（CreateOrder），这个操作是放在 MemberBO中呢？还是放在OrderBO中呢？

这个问题主要就是对象定义不明确产生的。如果我们将用户对象（User Object）、数据对象(Data Object)分开就不会有问题了。

比如：会员是系统用户的一种，我们定义 MemberUO，所有会员能对系统发送的操作指令都定义为这个类的方法。比如：下订单就定义为：MemberUO.createOrder（）。而会员数据对象定义为 MemberInfoDO，这个对象理解为系统执行业务流程过程中产生的数据对象。比如：会员执行注册操作，系统通过“会员注册业务处理流程”产生会员信息对象，最终保存到数据库中。

这样，我们的对象定义就清晰了。会员用户执行操作，系统针对用户操作执行业务处理流程生成数据对象，最终保存到数据库中。可表达为：

MemberUO.regist();
MemberInfoDO=MemberBO.regist();
MemberInfoDAO.save(MemberInfoDO);

同样的：下订单这个操作是会员发起，那么操作方法自然应该定义在MemberUO中，比如： MemberUO.createOder();

对应的，MemberBO中定义创建订单业务流程处理方法，比如： MemberBO.createOrder();

在业务处理流程中产生订单数据对象， OrderInfoDO，最终 MemberBO 使用 OrderInfoDAO 保存 OrderInfoDO。比如： OrderInfoDAO.save(OrderInfoDO)。

Look，BO 与 UO 是对应的（MemberBO 里的业务处理方法，对应 MemberUO 中的功能操作方法）而DAO 与 DO 是对应的（OrderDAO 操作的是 OrderDO）。

最后，框架的整合。结合spring mvc，可以轻松实现。我们只要把 MemberUO 在spring中打上 @Controller 标签，把MemberUO 中的所有方法打上 @RequestMapping 就可以了。所有 UO 中的方法都可以一一对应现实用户的功能操作。

注意：MemberBO 是系统针对 MemberUO 所有功能操作的业务处理方法集，而不是针对数据对象的（MemberInfoDO）。所以我们很自然的把 CreateOrder 业务处理方法放在 MemberBO 中，而不是放在 OrderBO中。

实际上，在整个系统中 Order 都不是一个用户对象，他只是一个数据对象（OrderInfoDO）。所以不会有 OrderUO ，也不会有OrderBO。同样的还有产品对象、保单对象、存款对象等等。切记，这些对象只是用户在执行系统功能时，系统执行业务处理流程过程中产生的数据信息。通常他们也是造成系统对象定义混乱的原因。