public String add() { } logger.debug(\增加\员工信息%userService.save(prpDuser); return SUCCESS; 注意，在Action中的所有logger必须为debug级别。
2.5 异常规范开发
在action中可以直接throw出我们已经定义好的集中异常方式（其中最为常用的BusinessException）,可以视具体逻辑而定。
不过并不支持在开发中使用try catch 进行自定义的异常处理。不过有些时候不能避免，那就需要各位再异常处理的时候多加小心。出了异常不要仅仅catch住了就仅仅打印出了异常信息而程序还能继续执行，这样对系统来说可能是破坏性。
3 业务服务开发
业务服务才是我们行业系统的核心价值，也就是说，我们的业务处理逻辑全部在业务服务层进行开发和完善。所以说对次层级的规范就是对整个系统的规范。
3.1 接口规范开发
接口开发的诸多好处我在此处我就不说了,此处我们就是要求每一个服务实现类都需要对应一个接口类，而在action中调用的都是接口类。具体的接口和实现类的映射交给spring来做就可以了。
同样实现类要实现接口类的方法。
3.2 服务调用规范开发
业务服务也可能需要其他服务的支持才能完成相关的业务操作，所以服务中调用其他服务也是很常见的。
此处的服务调用与Action调用并无大异，大家可以参看2.3进行学习。
3.3 Log规范使用
参看2.4进行学习
3.4 异常规范使用
参看2.5进行学习
3.5 缓存规范使用
为了提高性能我们经常使用缓存来保存常用的数据以减少数据库相应的时间，从而提高整个系统的性能。所以我们会在服务中增加必要的缓存，下面我们就来看看具体的操作步骤。
/** * 初始缓存实例 */ private static CacheService cacheManager = CacheFactory.getIntance( CodeConstants.CACHE_TYPE, \); 通过缓存工厂使用Company名称创建一个静态的cacheManager,对与Company的
cacheManager在整个工程是可见的，也就是说，如果其他的类同样使用了Company进行
创建cacheManager的话，这些cacheManager是统一管理的，所以说清大家注意命名的唯一性。
String key = cacheManager.generateCacheKey(\, codeType, cacheManager.putCache(key, page);
riskCode, language, matches, pageNo, pageSize, typeParam, extraCond); Object result = cacheManager.getCache(key); if ((Page) result != null) { } Do something; return (Page) result;
return page; 以上是具体的操作步骤：
? 通过关键字生成需要保存的key值，用于唯一一个缓存的值 ? 通过key值或者当前的缓存对象，是否包含此值 ? 如果有则使用缓存的具体值并返回
? 如果没有此缓存的话，则执行具体的方法，然后在执行完成后根据已经生成的key保存
的缓存中以便以后使用。
3.6 基类继承规范
了解分层的同时可能发现一个问题，我们的框架里并没有我们常规意义上的DB层，仅仅存在UI，Biz层。这个DB其实在我们框架里是存在的，下面我们来说一下如何再现DB层。
public class UserServiceSpringImpl extends GenericDaoHibernate
是需要实现的接口类，而GenericDaoHibernate就是我们的DB层了。
我们封装后的GenericDaoHibernate继承了我们所会用到的所有的DB层操作，所以，
我们在业务层的实现类中继承这个类后就可以在业务层中完全的操作DB了，这样就可以在一定程度上做到业务层和DB层的融合。
GenericDaoHibernate
通过泛型的定义可以使DB的使用更加的简单，当让这泛型也可以并不定义，不过使用的时候就需要制定需要操作的具体PO对象类了。
4 组件服务使用
作为一个通用的样本程序，不单单存在以上的业务开发环节就可以满足所有的开发和技术要求，这一章我们就会看到已经融合在我们样本程序中的很多技术的服务组件，可以给我
们的样本程序带来很多活力和技术特点。
4.1 异常的规范使用
在上面的开发知道中我们也提到了异常的使用规范，原则就是可以直接throw业务异常，而尽量避免try catch处理逻辑，就算不能避免使用try catch的话，对出现的异常也需要精细化处理，不能只是简单的打印出一场堆栈，而程序还能继续执行，这样对系统来说可能是破坏性的。
我想这些规范我们也是会严格遵守，对于我们定位和解决问题会带来很多的好处。 现在很多的系统已经逐渐的挂在公网上了,在此我们不淡安全，不谈技术，只是说说这个异常。我们之前的异常处理已经做的非常的完备了，如果抛出异常的话，我们可以在页面上进行查看，并且能够查看非常完备和详细的异常堆栈信息，以便我们能很快的定位和解决问题。
不过如果有一天我们的系统挂在公网上的话，一旦出现异常的话很多人都可以通过这个异常堆栈来了解我们的命名规范和处理机制，对于我们来说是很不安全的，所以在此样本程序中我们做了些许的改动，可以通过参数来配置，异常的模式，分为开发和生产模式，开发模式中存在异常堆栈信息，而生产模式的话已有异常信息而没有堆栈信息，不过想定位问题的话还是可以通过异常的log进行定位。
4.2 Log的规范使用
4.2.1 Log4j
此样本程序使用的Log4j作为log的管理工具，上面已经提到了如何在程序中使用这个log，这里就不在赘述了，此处我们就说说如何配置即可。
具体的log4j的相关资料可以参看《log4j参考手册》
# UNCATEGORIZED log4j.rootCategory=ERROR, UNCATEGORIZED log4j.appender.UNCATEGORIZED=org.apache.log4j.RollingFileAppender log4j.appender.UNCATEGORIZED.MaxFileSize=10MB log4j.appender.UNCATEGORIZED.MaxBackupIndex=5 log4j.appender.UNCATEGORIZED.File=log/uncategorized.log log4j.appender.UNCATEGORIZED.layout=org.apache.log4j.PatternLayout log4j.appender.UNCATEGORIZED.layout.ConversionPattern=%d %p [%c] - <%m>%n #user log4j.category.ins.arch4platform.platform=DEBUG, PLATFORM log4j.additivity.ins.arch4platform.platform=false log4j.appender.PLATFORM=org.apache.log4j.ConsoleAppender log4j.appender.PLATFORM.layout=org.apache.log4j.PatternLayout log4j.appender.PLATFORM.layout.ConversionPattern=%d %p [%c] - <%m>%n #exception log4j.category.ins.arch4platform.common.ExceptionMessageBean=ERROR, EXCEPTION log4j.additivity.ins.arch4platform.common.ExceptionMessageBean=false log4j.appender.EXCEPTION=org.apache.log4j.RollingFileAppender log4j.appender.EXCEPTION.MaxFileSize=20MB log4j.appender.EXCEPTION.MaxBackupIndex=5 log4j.appender.EXCEPTION.File=log/exception.log log4j.appender.EXCEPTION.layout=org.apache.log4j.PatternLayout log4j.appender.EXCEPTION.layout.ConversionPattern=%d %p [%c] - <%m>%n 此配置文件分为3个部分，第一部分为基本部分可以记录下面几部分未能涉及到的范围，并进行管控。
第二部分为ins.arch4platform.platform进行管控，实现的是在此包下面的log，debug级别以上的log都会打印在console上。