J2EE中MVC的各层的设计原则及其编写注意事项

总结了下J2EE的MVC模式开发原则，很多细节处理好了是很有利于开发与维护的。

下面就从各层说起。

视图层

主要是客户端的显示，主要是JSP和HTML，随着Web的不断发展，许多基于Javascript的富应用客户端不断出现，越来越流行通过JSON格式进行前后台数据交互。

控制层：

Control：

作为处理分发器，组装前台需要的数据给客户端。

服务层（Service 业务逻辑层）：

存放业务控制，在Service层中将dao的操作组合起来放入事务中。操作文件之类的都放到Service中。

Service中尽量复用dao中的操作，涉及到一张表产生的业务放入到dao中。

VO（Value Object，ViewObject）是符合Java Bean属性规范的简单Java对象，由new关键字创建，由业务逻辑使用，为数据提供一个生存的地方。主要对应界面显示数据的对象，用一个VO对应一个请求的所有数据。

Dao（数据访问层）：

dao：

存放基本的操作，真正起到数据库的操作。

Dao只能操作单表，跨表的操作，放到Service中。

Model：

一般来所一张表对应一个Model，一些中间表就不用创建Model，可以把中间表操作的相关方法直接写到和中间表相关的Model中。

Domain：

是一个范围，接线，作为一个领域，常放到一个包中。

　　分层的好处：架构与管理，增加可维护性。这里特别强调的就是命名规范。先架构再编码。

分层开发遵守的原则：

① 上层依赖于下层，依赖关系不跨层；

② 一切设计都从Service层出发，作为一个系统首先需要把握其业务。从系统需要提供的功能进行分析，来确定Service接口中的方法，而不是从数据库出发到dao和Domain，再到Service层。不要对系统分层产生了误解，还是从最重要的功能来考虑的；

③ 事务控制放到Service中；

④ Service层的设计，需要考虑控制Service的数量，通常将一个模块的服务放到一个Service中来处理，从Service层往下看，接口逐渐增多；

⑤ 服务层的实现依赖于领域活动。最核心的设计就是将系统中的实体划分为领域模型，在此基础上设计dao层，再把这些操作暴露给Service层；

⑥ 每一个接口的职责范围有明确目的。这样设计是有问题的：一表对应一个dao，一个dao对应一个domain，一个domain对应一个Service，导致Service接口和dao的接口基本一致。最终Service里面太多的方法，然后，只能在Control层中反复调用Service，这样的代码是不堪入目的。可以这样做，一个domain活动聚合对应的一组dao来完成领域活动，而在Service也可能包含两个domain活动；

⑦ 每一个层中的接口都关注自己的那一块，不能在一个Dao中随意操作别的表，这样只能让项目更加难以维护。

本文链接：http://www.itzhai.com/j2ee-mvc-based-layers-of-design-principles-and-its-writing-note.html