最近要开始一个新项目，上一个项目采用贫血的多层构架，感觉IDao，IService大多数都无用，虽然有IDE辅助但是仍然很痛苦，想请教一下大家在实践中是怎么使用多层构架的。
DAO层是否有必要存在？毕竟对于一个电商网站你不太可能将数据序列化到文件吧，而且采用Redis等内存数据库也要特殊处理吧，不会直接替换一个DAO实现了事吧。如果只是作为关系数据库的封装，ORM也已经封装的不错了，Java中的常用的ORM也就Hibernate和ibatis一般根据人员学习成本相比中途也不会无痛切换吧。
Service层什么情况下才需要有不同的实现类？Service不过是作为一些代理和跨dao,entity的调用，直接替换不同DAO实现来更换持久化方案我能理解，但是什么情况下才需要替换Service的具体实现呢？
开始时接口是否有必要存在？开始就采用接口基本就要两个文件来回跳来跳去，如果开始时候就直接使用实现类直到需要时在引入接口成本是否会很高？毕竟只是声明类型变了，业务逻辑没变。（该问题已有同学回答，参见每一个类都应该有一个接口吗？）
引用别人对贫血模型和充血模型的总结(没记错的话应该是javaeye的robbin总结的)：
对于Java来说，更加适合采用贫血的模型，Java比较适合于把一个复杂的业务逻辑分离到n个小对象中去，每个小对象描述单一的职责，n个对象 互相协作来表达一个复杂的业务逻辑，这n个对象之间的依赖和协作需要通过外部的容器例如IoC来显式的管理。但对于每个具体的对象来说，他们毫无疑问是贫 血的。
这种贫血的模型好处是：
1、每个贫血对象职责单一，所以模块解藕程度很高，有利于错误的隔离。
2、非常重要的是，这种模型非常适合于软件外包和大规模软件团队的协作。每个编程个体只需要负责单一职责的小对象模块编写，不会互相影响。
贫血模型的坏处是：
1、由于对象状态和行为分离，所以一个完整的业务逻辑的描述不能够在一个类当中完成，而是一组互相协作的类共同完成的。因此可复用的颗粒度比较 小，代码量膨胀的很厉害，最重要的是业务逻辑的描述能力比较差，一个稍微复杂的业务逻辑，就需要太多类和太多代码去表达(针对我们假定的这个简单的工时管 理系统的业务逻辑实现，ruby使用了50行代码，但Java至少要上千行代码)。
2、对象协作依赖于外部容器的组装，因此裸写代码是不可能的了，必须借助于外部的IoC容器。
对于Ruby来说，更加适合充血模型。因为ruby语言的表达能力非常强大，现在用ruby做企业应用的DSL是一个很热门的领域，DSL说白了就是用来描述某个行业业务逻辑的专用语言。
充血模型的好处是：
1、对象自洽程度很高，表达能力很强，因此非常适合于复杂的企业业务逻辑的实现，以及可复用程度比较高。
2、不必依赖外部容器的组装，所以RoR没有IoC的概念。
充血模型的坏处是：
1、对象高度自洽的结果是不利于大规模团队分工协作。一个编程个体至少要完成一个完整业务逻辑的功能。对于单个完整业务逻辑，无法再细分下去了。
2、随着业务逻辑的变动，领域模型可能会处于比较频繁的变动状态中，领域模型不够稳定也会带来web层代码频繁变动。
- 为什么Java只适合贫血模型？
- 有没有什么场景下可以允许所有业务逻辑和持久化全部揉在Model中。
1、DAO层是否有必要存在？
-->使用mybatis的mapper当dao就可以了，如果再封一层dao，略显多余
2、Service层什么情况下才需要有不同的实现类？
-->其实service层的接口根据使用场景，一般大部分可以去掉。需要有不同实现类的情况看需求，比如现在的需求是要导出excel2003格式的，以后可能会有需求要导出excel2007的，做个接口就比较灵活
3、开始时接口是否有必要存在？
-->对系统外暴露的api服务，要有接口，系统内的话，接口看情况而定
4、为什么Java只适合贫血模型？
-->跟静态类型相关的，其实不一定要局限贫血、充血模型，便于使用和维护就可以。
5、有没有什么场景下可以允许所有业务逻辑和持久化全部揉在Model中
-->为什么要揉到model里头呢，其实可以简化service层，采用命令模式，把业务逻辑放到命令里头，这样既可以避免service层无限庞大，可以保持精简，也可以使得业务逻辑相对独立可测。