本文主要是介绍J2EE基于MVC的各层的设计原则及其编写注意事项，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
总结了下J2EE的MVC模式开发原则，很多细节处理好了是很有利于开发与维护的。
主要是客户端的显示，主要是JSP和HTML，随着Web的不断发展，许多基于Javascript的富应用客户端不断出现，越来越流行通过JSON格式进行前后台数据交互。
作为处理分发器，组装前台需要的数据给客户端。
存放业务控制，在Service层中将dao的操作组合起来放入事务中。操作文件之类的都放到Service中。
Service中尽量复用dao中的操作，涉及到一张表产生的业务放入到dao中。
VO（Value Object，ViewObject）是符合Java Bean属性规范的简单Java对象，由new关键字创建，由业务逻辑使用，为数据提供一个生存的地方。主要对应界面显示数据的对象，用一个VO对应一个请求的所有数据。
存放基本的操作，真正起到数据库的操作。
Dao只能操作单表，跨表的操作，放到Service中。
一般来所一张表对应一个Model，一些中间表就不用创建Model，可以把中间表操作的相关方法直接写到和中间表相关的Model中。
是一个范围，接线，作为一个领域，常放到一个包中。
分层的好处：架构与管理，增加可维护性。这里特别强调的就是命名规范。先架构再编码。
① 上层依赖于下层，依赖关系不跨层；
② 一切设计都从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中随意操作别的表，这样只能让项目更加难以维护。
最后说一句话吧：拙略的架构设计会降低系统的性能，不要从框架和数据库或应用服务器上找错，尝试优化一下自己的设计。
这篇关于J2EE基于MVC的各层的设计原则及其编写注意事项的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
