J2EE基于MVC的各层的设计原则及其编写注意事项
来源:互联网 发布:凯迪网络手机版 编辑:程序博客网 时间:2024/05/22 13:21
总结了下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的各层的设计原则及其编写注意事项
- J2EE中MVC的各层的设计原则及其编写注意事项
- 基于MVC的web框架---模型层设计
- 开发基于J2EE架构的若干原则
- 开发基于J2EE架构的若干原则
- 基于J2EE的MVC设计模式的WEB应用开发应用及探讨
- 光源照明的设计原则及注意事项
- 架构设计的一点想法——MVC架构和及其胶合层的思考
- J2EE的体系结构和MVC设计模式
- 基于WebGIS的电子政务应用(基于J2EE的MVC架构)
- 编写基于DSP程序的注意事项
- J2EE DAO层和业务逻辑层的设计
- Apple,Google, 及其它的设计原则
- ASP.net MVC基于EntityFrameWork 的 MODEL层控制反转(IOC)架构设计
- 基于J2EE的电子商务开发模型及其实现
- 基于J2EE的电子商务开发模型及其实现
- MVC设计模式及其带来的优点
- win2k环境下基于JBOSS的J2EE开发实践----之四:BMP实体Bean的编写与设计
- Simplify Path
- Linux下用g++编译c程序
- UVA11324_The Largest Clique_tarjan求强连通分量+DP求最长路
- CF 192 DIV.2
- POJ题目分类
- J2EE基于MVC的各层的设计原则及其编写注意事项
- ETL的过程原理和数据仓库建设
- 130720CF解题报告
- 判断顶点是否位于三角形内
- ZK grid or list数据多列排序
- UVAlive 5864 Register Allocation 题解
- OpenCV 编码样式指南
- 使用json-lib将xml转换为json
- vs2010 快捷键大全