关于pojo、dao、service的困惑

执念 或者说 走火入魔 是我们在学习实践过程中应该注意防范的

比如李小龙出招前喜欢 摸摸鼻子 尖叫两声

并不代表必须 摸摸鼻子 尖叫两声 才是武林高手

不是很理解阿，慢慢体会吧，可能维护起来会方便些吧。

很多东西加了，不代表不好，因为你总要给以后出现什么乱七八糟的情况留下点修改的空间，但是加多了，又感觉凌乱。所以这个东西就象自己的屋子，怎么设计，怎么放东西有自己的个人的爱好，我觉得现在很多系统设计里面都残留了，当初决策者的痕迹在里面。

业务代表，业务代表工厂，DAO模式，DAO工厂，业务层进行事务处理，这些概念如果了解的话，不难理解为什么这么多项目如此设计。随着ORM的深入人心，我更喜欢springside让service直接继承DAO的做法。

    个人感觉，架构层次的多少和你的项目的复杂程度以及项目的性质密切相关。如果项目很小而且只是一个“一次性”的项目，那么引入太多的抽象层并不会带来太多的好处，反而大大增加了项目的复杂度。

    对于一个庞大的、需要不断升级、持续开发的项目而言，引入合理的多层架构和高度抽象还是非常有必要的，带来的价值并非一个“好”字能够形容。但是这并不是说一定要按照J2EE架构的“蓝图”来设计你的系统，在实际应用中，可以根据项目的需要进行合理的划分。

    比如，在一个项目中有screen(页面)、service(服务)、facade(门面)、dao(持久)、eis(资源)等几个层次，当然除screen外每个层都回有相应的Impl实现，并且系统中同时存在同步调用和异步调用两种模式。在这样一种架构设计中，按照正统的J2EE蓝图，应该是screen-->facade-->dao-->eis的调用逻辑。其他子系统如果要和该系统进行通讯，会调用相应的service。那么是不是就一定要严格按照这种方式进行调用呢？如果仅仅是“查询”这样不包含业务逻辑的简单操作，完全可以直接调用DAO来获取数据，再对DAO进行一层封装也是没有什么意义的，只会增加开发量，让开发人员厌烦！反过来说，如果包含了复杂的业务逻辑，进行合理的分层是必须的，这样可以在每个层中随意增加“控制”。

    DAO是业界一种公认的模式，就如同IoC一样。Hibernate功能的确非常强大，但是它能生成iBatis代码么？如果有一天出于性能的考虑，你们的老总决定不用Hibernate，而用iBatis，那你该如何进行替换呢？试想一下，如果没有一个合理的DAO层，那么这种替换的代价将会多高昂！

之所以有pojo、dao、service，主要的原因是OO和分层(layer)思想。至于OO对编程计算的意义和重要性这方面在这里就不做说明，找本书看就行。目前软件应用大多离不了数据库，而且大部分是关系型数据库，关系型数据的行列描述、存储、访问方式跟OO有着不可调和的矛盾，要在程序中使用数据，无论是通过底层的jdbc还是通过ORM这一层进行访问，所要做的工作都是把行列数据进行对象化，然后交给更高级的应用层使用这些对象，pojo在这种计算模型当中充当了内存中贮留数据的载体，为了封装（OO的思想之一）数据的访问机制，并进行高度的抽象化，使得这些访问能够适应种类繁多且访问方法不一的后台数据库，以及对高级应用层屏蔽实现方式，降低层间耦合，dao作为一种设计模式被提出，做法是利用了接口（也是OO的思想之一）声明数据访问方法，具体由dao的实现类(daoImpl)来进行实现，举一个例子，如果系统需要支持mysql和oracle数据库，各自实现具体的mysqlDaoImpl和oracleDaoImpl，而又为什么出现service，这是分层的设计思想引出的，分层强调每层各司其职，一层的改动不影响另一层，这样可以获得很好的弹性和维护性，也可以带来编程分工上面的好处，等等，那么根据工程实践，现在绝大多数的web应用系统都会采用如下分层模式，表现层(e.g. jsp)，控制层(e.g. servlet)，应用层(e.g. Session Bean)，数据访问层(Entity Bean or Dao)，这里所说的应用层其实就是service，它负责业务逻辑封装，而业务逻辑的实现大部分需要进行数据变更，也就是依赖于数据访问层，比如，一个例子就是银行转帐，需要从一个户头扣钱，然后打入另外一个户头，这种操作需要调用几个数据访问接口才能实现，数据访问接口在数据访问层（如dao）中提供，service再通过将这些接口“组装”形成一个个具体的业务方法，供调用完成实际业务。总而言之，为什么现在编程都是这几种方式，原因是目前的计算模型建立在OO和分层的思想上，然后产生了类似设计模式这样的方法论，具体在工程实践中产生了思想和方法的实际载体如框架，这些关系比较多，要在这讲讲个几天也讲不完，还是需要去循序渐进的在实践中总结，提高。

我们都知道在DAO里面一般放CURD这样的简单对数据操作，然后在Service层依据业务知识对DAO层开放出来的接口进行再次封装。但是我们经常会遇到这样的情况：在Service中需要对数据库中取出某几个字段，对这几个字段进行分析后再进行下一步业务处理，按道理，这些处理应该放在Dao层中，但是如果你的业务很多都要进行到如此情况，那么这样做是不是会造成Dao层中的接口泛滥呢？其次Service层中很多业务其实如果细细分析，会发现是可以抽象出来的，那么按照设计模式那些方法论来说，我们的Service层布局处理该怎么样又才是最有效果？

设计任何接口都会遇到粒度问题，从个人经验来说，Dao接口最好是细粒度；对于在Service层进行业务重用，这根据项目任务来定，不过从我的经验来说，如果单纯使用OO，业务重用比较困难，至多是组件级别的重用，比如新的Service可以调用老的Service接口，个人认为可以从AOP，SOA着手。

你说的没错，可是你的方法并不能减少class的数量

无聊，其实大部分工作不过是crud，非搞得这么形式化