一个经典的Spring IOC疑难症状释疑

最讨厌那种Dao Service Controller 都分别接口，然后再实现的代码了。
接口编程是在需要的时间用，而不是什么情况都用接口。一般的企业应用，Dao,Service,Controller直接使用类
可以节省不少代码和类，也不影响扩展性，接口应该在一些公用的框架（如我原来写过的Rop）中用。

Service定义接口是合适的，Dao可以薄一点直接使用实现类。Service原本就是起到隔离层次的作用，有多个实现是很正常的，所以用接口更合适。通常我们项目确定了架构后，DataAccess就不太会发生变化了，Dao用接口获得的好处其实不明显。

我觉得和便捷不便捷其实关系不大，主要是开发的时候可以隔离较为复杂的环境。所以绝大多数的企业应用我都会选择定义Service层的接口。

mark!

简单使用，基于接口编程即可

呵呵。万一你没用接口。今天用的sql。明天改成了mongodb。
或者发短信今天用移动平台，明天用联通平台。
并且换成另外一个人去写这个功能怎么办？
他没有接口，不知道该怎么定义方法才能切换其他协调任务。想怎么写就怎么写。过几天又有一个项目又换回来了。
接口本身就是一种约束，为了项目更好扩展和切换。
没有约束一时爽，但是那样的项目做不大，做不活。

其实楼主限定了一般的企业应用，我认为楼主说的情况是跟我想的一样：给自己使用的情况（可以理解为模块内的功能）；不能一棒子打死，接口是一种约束：我认为这个约束主要是朋友（即第三方）之间的约束；如果是自己使用你还写个接口我觉得就没啥必要性了。这个我认为还是一个权衡的问题。

现在使用java感觉其应该有一个模块级别的访问权限，这样可以把一些功能限定在一个模块内。

面向接口编程当然是好的习惯，
但是实际开发的时候 也要视情况而定 做一些小范围的 灵活处理是需要的 
如果实现什么功能都定义一个接口，然后一层层是实现，有时候确认感觉有点 多余！
（如果一个简单的业务，不设计第三方，基本也不会变 多一层接口 我感觉作用也不大！
实际开发中 我还是比较 偏向 楼主的做法！ 当然反对的人也很多！  ）
萝卜白菜 各有所爱吧！ ！

这个问题过于经典，以至于基本每本讲叙springAOP时，好像都会说到类似这样的例子。

这理解实在太肤浅了。自己使用就不用写接口了？模块内访问就没有写接口的必要性了？

在企业应用中，最大量使用接口的情况主要在于隔离编程层次和提供IoC扩展。因为很多情况下，企业应用的业务具体场景可能是不确定的，是在系统实现中不断完善的。所以使用接口可以让整个系统的架构和层次先确定下来，这也让团队工作的分派成为了可能。这东西和你是否和第三方程序交互没多大关系，和是否是内部使用也没多大关系。使用接口，纯粹是让IoC成为了我们一种主流的编程习惯而已。

话虽这么说，但是实践中，发现一般的企业应用Service，Dao使用接口除了陡增加类数量外，没有其它的好处，
倒是在写一些框架级 或 通用性的类库时，接口的作用就明显了。这是我个人开发的一个感受，原来我的企业信息系统也是都有接口的，到后面实在觉得这东西是一个束缚，到后来也是给解放了。

所以个人现在就是写企业应用三层都不用接口，直接用类，写框架，写类库就使用接口。