关于pojo、dao、service的困惑

用ssh框架开发有一阵了,但还是对怎样定义pojo、dao、service这三层不太理解。只是模仿着老员工,对每个数据库表建立一个pojo,一个映射文件,一个dao(接口),一个daoImpl(实现),一个service(接口),一个service(实现),这样数据库中如果有五张表,就会相应建立30个文件,感觉很是麻烦。有时pojo上面还有抽象类,那就是35个文件。

关于领域模型的设计问题,JavaEye已经组织过n多次大规模讨论,几乎每过一段时期就会出现一次。最近出现了一个新的趋势,Craig Walls在自己的blog上面写一篇文章,介绍如何使用Spring2.0和AspectJ的新特性给domain object注入DAO依赖,即如何实现post-instantiation,请见:
http://jroller.com/page/habuma?entry=spring_2_0_vs_the

与此同时,ajoo也给出了nuts的post-instantiation方案,请见:
http://www.iteye.com/display/ajoo/Dependency+Injection+For+Rich+Domain+Model

因此,从技术手段来上说,对于Spring/Hibernate架构,Martin的Rich domin model变得可行了,那么让我们看看究竟有哪些领域模型,以及他们的优缺点:

一、失血模型

失血模型请看
http://forum.iteye.com/viewtopic.php?t=11712
中列举的第一种模型,简单来说,就是domain object只有属性的getter/setter方法,没有任何业务逻辑。

二、贫血模型

贫血模型请看
http://forum.iteye.com/viewtopic.php?t=11712
中列举的第二种模型,简单来说,就是domain ojbect包含了不依赖于持久化的领域逻辑,而那些依赖持久化的领域逻辑被分离到Service层。
Service(业务逻辑,事务封装) --> DAO ---> domain object

这种模型的优点:
1、各层单向依赖,结构清楚,易于实现和维护
2、设计简单易行,底层模型非常稳定
这种模型的缺点:
1、domain object的部分比较紧密依赖的持久化domain logic被分离到Service层,显得不够OO
2、Service层过于厚重

三、充血模型
充血模型和第二种模型差不多,所不同的就是如何划分业务逻辑,即认为,绝大多业务逻辑都应该被放在domain object里面(包括持久化逻辑),而Service层应该是很薄的一层,仅仅封装事务和少量逻辑,不和DAO层打交道。
Service(事务封装) ---> domain object <---> DAO

这种模型的优点:
1、更加符合OO的原则
2、Service层很薄,只充当Facade的角色,不和DAO打交道。
这种模型的缺点:
1、DAO和domain object形成了双向依赖,复杂的双向依赖会导致很多潜在的问题。
2、如何划分Service层逻辑和domain层逻辑是非常含混的,在实际项目中,由于设计和开发人员的水平差异,可能导致整个结构的混乱无序。
3、考虑到Service层的事务封装特性,Service层必须对所有的domain object的逻辑提供相应的事务封装方法,其结果就是Service完全重定义一遍所有的domain logic,非常烦琐,而且Service的事务化封装其意义就等于把OO的domain logic转换为过程的Service TransactionScript。该充血模型辛辛苦苦在domain层实现的OO在Service层又变成了过程式,对于Web层程序员的角度来看,和贫血模型没有什么区别了。

四、胀血模型
基于充血模型的第三个缺点,有同学提出,干脆取消Service层,只剩下domain object和DAO两层,在domain object的domain logic上面封装事务。
domain object(事务封装,业务逻辑) <---> DAO
似乎ruby on rails就是这种模型,他甚至把domain object和DAO都合并了。
该模型优点:
1、简化了分层
2、也算符合OO
该模型缺点:
1、很多不是domain logic的service逻辑也被强行放入domain object ,引起了domain ojbect模型的不稳定
2、domain object暴露给web层过多的信息,可能引起意想不到的副作用。

在这四种模型当中,失血模型和胀血模型应该是不被提倡的。而贫血模型和充血模型从技术上来说,都已经是可行的了。但是我个人仍然主张使用贫血模型。其理由:

1、参考充血模型第三个缺点,由于暴露给web层程序拿到的还是Service Transaction Script,对于web层程序员来说,底层OO意义丧失了。

2、参考充血模型第三个缺点,为了事务封装,Service层要给每个domain logic提供一个过程化封装,这对于编程来说,做了多余的工作,非常烦琐。

3、domain object和DAO的双向依赖在做大项目中,考虑到团队成员的水平差异,很容易引入不可预知的潜在bug。

4、如何划分domain logic和service logic的标准是不确定的,往往要根据个人经验,有些人就是觉得某个业务他更加贴近domain,也有人认为这个业务是贴近service的。由于划分标准的不确定性,带来的后果就是实际项目中会产生很多这样的争议和纠纷,不同的人会有不同的划分方法,最后就会造成整个项目的逻辑分层混乱。这不像贫血模型中我提出的按照是否依赖持久化进行划分,这种标准是非常确定的,不会引起争议,因此团队开发中,不会产生此类问题。

5、贫血模型的domain object确实不够rich,但是我们是做项目,不是做研究,好用就行了,管它是不是那么纯的OO呢?其实我不同意firebody认为的贫血模型在设计模型和实现代码中有很大跨越的说法。一个设计模型到实现的时候,你直接得到两个类:一个实体类,一个控制类就行了,没有什么跨越。
好的,我现在要帮助这个用户完成他的毕业设计——基于SSM的在线音乐播放系统。用户是Java新手,没有任何基础,时间只有两个月,所以需要详细的开发流程和教程。首先,我需要理清整个项目的结构和步骤,确保每一步都清晰易懂。 用户提到的系统功能分为三块:用户管理、音乐管理、音乐播放。我应该从最基础的环境搭建开始,然后逐步引导他完成各个模块的开发。首先,得确保他安装好必要的开发工具,比如JDK、Maven、Tomcat、MySQL和IDEA。接下来是创建Maven项目,配置SSM框架,这可能会涉及到pom.xml的依赖管理,以及SpringSpring MVC和MyBatis的配置文件。 然后,用户管理模块需要设计数据库表,比如用户表的结构,包括用户名、密码等字段。接着是实体类、DAO层、Service层和Controller层的代码编写。这里要详细说明每个部分的作用,并提供示例代码。可能需要解释MyBatis的Mapper接口和XML映射文件的使用。 音乐管理模块涉及文件上传和存储,这里需要指导用户如何处理音乐文件的上传,存储路径的配置,以及数据库中的音乐信息管理。同时,音乐播放功能需要前端页面的支持,比如使用HTML5的audio标签,以及后端提供音乐文件流的接口。 考虑到用户的时间有限,每个步骤都需要详细但不过于复杂,避免让他感到困惑。可能需要分阶段指导,比如先完成环境搭建和项目配置,然后逐步实现各个功能模块。同时,要提醒他在开发过程中注意常见错误,比如依赖冲突、配置错误,以及文件路径的问题。 另外,用户可能对SSM框架不熟悉,所以需要解释每个框架的作用和它们之间的整合方式。例如,Spring的IoC和AOP,Spring MVC的控制器和视图解析,MyBatis的数据持久化等。通过简单的示例和注释,帮助他理解各个组件之间的关系。 最后,测试和部署也是重要的部分。需要指导他如何使用Postman测试接口,如何将项目打包成WAR文件并部署到Tomcat服务器上。可能还需要介绍一些基本的调试技巧,比如查看日志、断点调试等。 总之,我需要将整个开发流程分解成多个小步骤,每个步骤都提供详细的教程和代码示例,确保用户能够逐步跟进,顺利完成毕设。同时,语言要简洁明了,避免使用专业术语,或者在使用时进行解释,以符合他作为新手的理解水平。 以下是为您规划的2个月开发计划,今天我们先开始第一部分:环境搭建与项目初始化 # 一、第1周:环境准备与项目创建(建议用时3天) ## 1. 开发环境安装(必须严格按版本安装) ```markdown 1. JDK 1.8(官网下载安装,配置JAVA_HOME环境变量) 2. Apache Maven 3.6.3(配置MAVEN_HOME和仓库路径) 3. Tomcat 9(解压即可用) 4. MySQL 5.7(建议使用XAMPP集成环境) 5. IntelliJ IDEA 2023社区版(免费) ``` ## 2. 创建Maven项目(图文教程) 步骤: 1. 打开IDEA → New Project → Maven → 勾选`Create from archetype`选择`maven-archetype-webapp` 2. GroupId填`com.yourname`,ArtifactId填`music-system` 3. 确认项目路径 → 完成创建 ## 3. 基础pom.xml配置(复制即可) ```xml <dependencies> <!-- Spring核心 --> <dependency> <groupId>org.springframework</groupId> <artifactId>spring-webmvc</artifactId> <version>5.3.18</version> </dependency> <!-- MyBatis --> <dependency> <groupId>org.mybatis</groupId> <artifactId>mybatis</artifactId> <version>3.5.7</version> </dependency> <!-- MySQL驱动 --> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <version>8.0.27</version> </dependency> <!-- JSP支持 --> <dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>4.0.1</version> <scope>provided</scope> </dependency> </dependencies> ``` ## 4. 目录结构调整(必须严格遵循) ```bash src ├── main │ ├── java │ │ └── com │ │ └── yourname │ │ ├── controller │ │ ├── service │ │ ├── dao │ │ └── pojo │ ├── resources │ │ ├── spring │ │ │ ├── applicationContext.xml │ │ │ └── spring-mvc.xml │ │ └── mybatis-config.xml │ └── webapp │ ├── WEB-INF │ │ └── views │ └── static │ ├── css │ ├── js │ └── uploads ``` 下一步建议:是否需要我详细讲解每个配置文件的作用?或者您想先创建数据库?请告诉我您当前的进度和疑问。 详细解释每个配置文件的作用
03-08
### Controller 层的作用及实现 控制器(Controller)负责接收客户端请求并调用相应的服务方法来处理这些请求。通过`@Controller`注解标记的类定义了一个控制器类,在接收到HTTP请求时会寻找合适的方法进行处理[^2]。 ```java import org.springframework.stereotype.Controller; import org.springframework.web.bind.annotation.RequestMapping; @Controller public class ExampleController { @RequestMapping("/example") public String exampleHandler() { // 处理逻辑... return "viewName"; } } ``` ### POJO (Plain Old Java Object) POJO 是简单的Java对象,通常用于表示实体模型或数据传输对象(DTO)。这类对象不依赖于任何特定框架特性,仅包含属性及其getter/setter方法。 ```java public class User { private Long id; private String name; private int age; // Getters and Setters omitted for brevity. } ``` ### Service 层的作用及实现 业务逻辑层(Service Layer),也称为应用服务层,主要职责在于封装应用程序中的核心业务逻辑和服务接口。此层次的对象通常被标注为 `@Service` 注解,并且可以注入其他组件如DAO来进行持久化操作。 ```java import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Service; @Service public class UserService { @Autowired private UserDao userDao; public void createUser(User user){ // Business logic here... userDao.save(user); } // Other business methods... } ``` ### DAO 数据访问对象模式 数据访问对象(Data Access Object, DAO)提供了对底层数据库的操作抽象,使得上层代码无需关心具体的存储机制细节。对于采用直接JDBC方式的应用程序来说,DAO应该继承自`JdbcDaoSupport`;而对于Hibernate,则应扩展`HibernateDaoSupport`[^3]。 ```java import javax.sql.DataSource; import org.springframework.jdbc.core.JdbcTemplate; import org.springframework.orm.hibernate5.HibernateTemplate; import org.springframework.stereotype.Repository; @Repository public class UserDao extends HibernateDaoSupport { protected SessionFactory sessionFactory; public UserDao(DataSource dataSource) { setSessionFactory(sessionFactory); } public void save(User user){ getHibernateTemplate().saveOrUpdate(user); } // CRUD operations... } ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值