面象对象 业务层 DAO层 领域模式

以前做过的项目与学习，代码方面差不多，都是Jsp－＞Action－＞Service－＞Dao，认何一个功能，都是以提交与功能，把上面的过程过一遍，哪么就完成了，从来没有细细的想过业务层与DAO层他们真正的边界与责任，seamanly今天与我的谈话，让我知道了一些新的东西，先记下来

DAO层
在写DAO时，不需要太多的关心业务，业务层只会告诉DAO层需要什么数据，需要关心的是如何与数据库打交道，对数据库做什么样操作，多数为增、删、查、改，DAO层面对的是数据库，而不是用户，打个比方，修改数据与逻辑删除（修改字段表示此数据失效），相对于业务或用户来说，这是两个完全不同的操作，但对于数据库来说，都是对数据做修改操作，如操作的是同一个表，都可归纳到同一个DAO操作中

业务层
１、业务层的实现类，不可暴露出来，每一个实现类，使用单例模式，对实例化进行限制
２、业务层提供的接口，越简单越直接越好，如删除只需要ID时，业务层不需要得到一个OBJECT（如VO等等），当使用着看到接口时，就能明白，此接口可以提供什么功能，而不是数据。
３、每一个业务层接口，所提供的都是一个功能，也许多个功能部分有重复，但为了更直观，应提供每个功能一个接口

领域模式
这个感觉更多的是面向对象的思想，VO、DTO、PO等数据传输的模式或对象，可以定义一些属性，而这里要提出的不只是一些简单属性，每一个这样的Bean，应有与自己想关的些许业务，或是说功能，而Bean不可直接调用DAO来实现业务，而应调用业务层来完成功能


最后还提到一点，写代码时，应要抱着业务合法的心态去完成，业务规则的维护，应使用异常去处理，一个项目设计是否合理，看看自定义异常，也许能看出来，自定义异常写起来不难，但想真真的用好，也不简单