一些设计思想

【总的思想】
1、以业务层（领域模型）为核心
2、高内聚、低耦合

【特点】
1、将DAO接口置于业务层；
2、在数据访问层实现DAO接口，PO服务于DAO接口

【分层】
显示层－业务层－数据访问层（下面简称数据层）
业务层：细分为事务层－操作层－实体层－DAO接口，DAO接口进一步分为读接口和写接口
数据层：DAO实现＋PO
显示层：这个比较简单，用MVC框架，然后调用业务层即可

【业务层与数据层的关系】
数据层服务于业务层，业务层定义数据访问的接口（DAO接口），数据层来实现，数据层的PO是为了持久化的目的设计的，这也是PO唯一的存在价 值，PO不属于业务层范畴，不具备反映业务逻辑的职责，它的活动范围被严格限制在数据层之内，换句话说，无论是业务层还是显示层都不能引用PO。

是否设计PO与所使用的持久化技术有关，如果业务实体能够直接拿来持久化，而且性能没有问题，那么就不需要单独设计PO。总之PO属于数据层的实现细节，业务层的设计可以不考虑PO的任何问题，只管提DAO接口就是了。当然DAO接口只能用业务实体做参数，而不能有PO。

【业务层的设计原则】
事务层：包含事务的业务逻辑。必须定义接口。如果用Spring，则在此层绑定事务
操作层：不包含事务的业务逻辑。必须定义接口
实体层：包含简单的、操作自身和聚合边界内其它实体的业务逻辑。接口定义不是必须的。可变的、不稳定的业务逻辑通过在操作层、事务层应用策略模式等方式解决。
DAO接口：接口的语义仅限于反映实体的持久化操作，比如create、update、delete、findByXXX，DAO接口不能带有业务语义。不遵守这个原则会造成业务逻辑与数据逻辑的混淆，不符合高内聚的最高原则

【依赖关系】
总的依赖方向：显示层->业务层<-数据层
显示层可以引用：事务层、操作层、实体层和读的DAO接口，不可以引用写的DAO接口
事务层可以引用：事务层、操作层、实体层和读写的DAO接口
操作层可以引用：操作层、读的DAO接口和实体层
实体层不可以引用其它任何层的接口，包括DAO，实体的操作限于其聚合边界内

显示层还有一个有趣的技术就是，用Struts的话，将业务实体直接放到FormBean里面作为它的一个JavaBean属性，而不是根据页面 定义一大堆String属性，页面通过x.x.x访问对象图的方式绑定数据，这样可以大大简化显示层的开发。（可能很多人都是这么用的，只是我们才刚刚醒 悟过来）。至于有人提出的业务层一变，显示层会跟着变的问题，这就看你想让谁依赖谁了，你总要确定一个依赖方向，不可能谁也不依赖谁（变通的办法是再加一 层，然后都依赖它，如果你愿意的话……），最开始就讲了，架构总的原则是以业务层为核心，这就决定了其它层都必定是依赖与业务层的，我实在是想不出为什么 不能依赖业务层。

关于Service，我不太喜欢这个概念（还有Facade），它真的能起到应有的作用吗？它究竟是让接口变简单了呢还是增加了系统整体的复杂程 度？jdk那么复杂，也没什么Service层啊！我们用jdk或者Hibernate的时候就看它的api和reference，那么显示层用业务层的 时候，也去看业务层的api和reference不结了？

 

 

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

 

 

 

                JAVA SSH框架
JAVA SSH框架在Struts + Spring + Hibernate的组合框架模式中，三者各自的特点都是什么？

Struts 的MVC设计模式可以使我们的逻辑变得很清晰。
Spring 的IOC和AOP可以使我们的产品在最大限度上解藕。
hibernate的当然就是实体对象的持久化了

典型的J2EE三层结构，分为表现层、中间层（业务逻辑层）和数据服务层。三层体系将业务规则、数据访问及合法性校验等工作放在中间层处理。客户端不直接与数据库交互，而是通过组件与中间层建立连接，再由中间层与数据库交互。

表现层是传统的JSP技术，自1999年问世以来，经过多年的发展，其广泛的应用和稳定的表现，为其作为表现层技术打下了坚实的基础。

中间层采用的是流行的Spring+Hibernate，为了将控制层与业务逻辑层分离，又细分为以下几种。

Web层，就是MVC模式里面的“C”（controller），负责控制业务逻辑层与表现层的交互，调用业务逻辑层，并将业务数据返回给表现层作组织表现，该系统的MVC框架采用Struts。

Service层（就是业务逻辑层），负责实现业务逻辑。业务逻辑层以DAO层为基础，通过对DAO组件的正面模式包装，完成系统所要求的业务逻辑。

DAO层，负责与持久化对象交互。该层封装了数据的增、删、查、改的操作。

PO，持久化对象。通过实体关系映射工具将关系型数据库的数据映射成对象，很方便地实现以面向对象方式操作数据库，该系统采用Hibernate作为ORM框架。

Spring的作用贯穿了整个中间层，将Web层、Service层、DAO层及PO无缝整合，其数据服务层用来存放数据。

一个良好的框架可以让开发人员减轻重新建立解决复杂问题方案的负担和精力;它可以被扩展以进行内部的定制化;并且有强大的用户社区来支持它。框架 通常能很好的解决一个问题。然而，你的应用是分层的，可能每一个层都需要各自的框架。仅仅解决UI问题并不意味着你能够很好的将业务逻辑和持久性逻辑和 UI 组件很好的耦合。

采用Hibernate作为持久层技术的最大的好处在于：可以完全以面向对象的方式进行系统分析、系统设计。

DAO模式需要为每个DAO组件编写DAO接口，同时至少提供一个实现类，根据不同需要，可能有多个实现类。用Spring容器代替DAO工厂

通常情况下，引入接口就不可避免需要引入工厂来负责DAO组件的生成。Spring实现了两种基本模式：单态模式和工厂模式。而使用Spring可以完全避免使用工厂模式，因为Spring就是个功能非常强大的工厂。因此，完全可以让Spring充当DAO工厂。

由Spring充当DAO工厂时，无须程序员自己实现工厂模式，只需要将DAO组件配置在Spring容器中，由 ApplicationContext负责管理DAO组件的创建即可。借助于Spring提供的依赖注入，其他组件甚至不用访问工厂，一样可以直接使用 DAO实例。

优点：
Struts跟Tomcat、Turbine等诸多Apache项目一样，是开源软件，这是它的一大优点。使开发者能更深入的了解其内部实现机制。
除此之外，Struts的优点主要集中体现在两个方面：Taglib和页面导航。Taglib是Struts的标记库，灵活动用，能大大提高开发 效率。另外，就目前国内的JSP开发者而言，除了使用JSP自带的常用标记外，很少开发自己的标记，或许Struts是一个很好的起点。
关于页面导航，我认为那将是今后的一个发展方向，事实上，这样做，使系统的脉络更加清晰。通过一个配置文件，即可把握整个系统各部分之间的联系，这对于后期的维护有着莫大的好处。尤其是当另一批开发者接手这个项目时，这种优势体现得更加明显。
缺点：
Taglib是Struts的一大优势，但对于初学者而言，却需要一个持续学习的过程，甚至还会打乱你网页编写的习惯，但是，当你习惯了它时，你会觉得它真的很棒。
Struts将MVC的Controller一分为三，在获得结构更加清晰的同时，也增加了系统的复杂度。
Struts从产生到现在还不到半年，但已逐步越来越多运用于商业软件。虽然它现在还有不少缺点，但它是一种非常优秀的J2EE MVC实现方式，如果你的系统准备采用J2EE MVC架构，那么，不妨考虑一下Struts。