SPRING全应用供参习.docVIP

SERVICE层编码规范 目录 1. 设计思想 2 1.1. 敏捷设计概念 2 1.2. 单一职责原则（SRP） 2 1.3. 开放-封闭原则（OCP） 2 1.3.1. 关键是抽象 3 1.4. 里氏代换原则（LSP） 3 1.5. 依赖倒置原则（DIP） 4 1.5.1. 层次化 4 1.5.2. 使用spring来应用该原则 4 1.6. 接口隔离原则（ISP） 6 2. Spring框架的使用 7 2.1. 容器 7 2.1.1. 配置元数据 7 2.1.2. BEAN的命名规范 8 2.1.3. 实例化bean 8 2.1.4. 配置文件bean属性详解 9 2.1.5. Bean定义的继承 10 2.2. AOP编程 11 2.2.1. 概念 11 2.2.2. Spring AOP的支持方式 11 2.2.3. Spring AOP使用例子（@AspectJ方式） 11 2.2.4. Spring AOP使用例子（context配置方式） 12 2.2.5. 切入点类型支持 12 2.3. 测试 13 2.3.1. 使用spring工具简化测试 13 2.4. WEB服务的应用 15 2.5. Spring中的定时调度 15 2.6. 事务处理 15 2.6.1. 使用CONTEXT配置声明式事务管理 15 2.6.2. 使用注解方式声明事务 19 设计思想 SERVICE层整个WEB系统中负责业务逻辑处理的一块，是最需要抽象的部分，这一层设计的核心就是复用性，和低耦合性，结合spring提供的依赖注入方式，让业务逻辑的处理的代码调用更方便 敏捷设计概念 敏捷设计是一个过程，不是一个事件，它是一个持续的应用原则，模式以及实践来改进软件的结构和可读性的过程。敏捷开发人员应该做到的： (1)他们遵循敏捷实践去发现问题； (2)他们应用设计原则去诊断问题； (3)他们应用适当的设计模式去解决问题 对于我们的营销系统，改进目前框架复杂，高耦合，低移植性的最佳方法就是抽象，在应用抽象的思想时，我们需要尽量的遵循以下几种设计原则： 单一职责原则（SRP） 就一个类而言，应该仅有一个引起它变化的原因。职责简单一些，复用更加轻松。 手机虽然可以拍照，但是效果很差。 如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其它职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。 如果你能够想到多于一个的动机去改变一个类，那么这个类就具有多于一个的职责，那就需要将类的职责分离。 在SERVICE的设计时，一个接口或者类一定要仅满足一个抽象的业务需求，如果有多于一个的时候，就需要把类拆分开来 开放-封闭原则（OCP） 本原则是说：软件实体（类、模块、函数等等）应该可以扩展，但是不可修改。面对需求的改变却可以保持相对稳定，从而使得系统可以在第一个版本以后不断推出新的版本。 无论模块是多么的“封闭”，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须先猜测出最有可能发生的变化种类，然后构造抽象来隔离那些变化。 在我们最初编写代码时，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后发生的同类变化。面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码——这就是开放封闭原则的精神所在。 关键是抽象 例如我们的划分功能，可能有多种划分方式，而根据不同的客户类型，可能会使用不同的划分方式，这时候我们就应该把划分方式抽象为一个接口，或者抽象类，这样我们使用时只通过接口来调用，而不关心具体实现，如果有新的划分方式我们只需要增加一个实现，而不需要再改变接口了 注意：以后如果有这种业务的不同方式，都应该使用抽象来调用，比如营销单的派单方式，维系挽留的不同预警类型，都应该使用抽象来设计 里氏代换原则（LSP） 白话：一个软件实体如果使用的是父类的话，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别[ASD]。也就是说，在软件里面，把父类都替换成它的子类，程序的行为没有变化。简单地说，子类型必须能够替换掉它们的父类型。 只有当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。参见下面的代码： 动物* animal = new 猫(); animal-吃(); animal-喝(); animal-叫(); 如果需求发生变化，需要将“猫”更换成别的动物，只需要更改第一句即可，其它地方无需改变。这就是“面向接口编程”的好处。 依赖倒置，其实就是谁也不要依靠谁：除了约定的接口，大家都可以灵活