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中随意操作别的表,这样只能让项目更加难以维护。

最后说一句话吧:拙略的架构设计会降低系统的性能,不要从框架和数据库或应用服务器上找错,尝试优化一下自己的设计。(总结修改中…)

arthinking wechat
欢迎关注itzhai公众号