关于web层与业务层的接口问题

写代码中想到一个问题，
1.业务层先写了接口，然后再实现了它
2.不写接口直接在业务层写函数实现
两者有什么区别，写接口的好处是什么？？

去看Rod Johnson的《J2EE Development without EJB》，里面有详细的论述，为什么要面向接口编程。

正在看，还没看到呢，让我来找找

接口把定义与实现分离，它反映了系统设计人员对系统的抽象理解，它可以把模块组件化，利于模块之间的交互，这次项目构架个框架，但是对我来说真的有点难，就从这个面向接口的编程开始吧。
在设计模式中真的很重视实现与接口分离，原因有下面几个：
1. 对一般的程序员来说，他们不需要知道具体的实现，只需要清楚接口发布出的方法就可以了。
2.因为接口是需求中比较稳定的部分，而实现则是和具体的环境相关联的，只要满足接口，其它软件开发团队同样能够开发出合用的应用来。在当前这样一个讲求合作、讲求效率的大环境中。这种开发方法是非常重要的。
大家觉的呢？？

个人觉得业务层的接口也并不稳定，也经常会有变动，相对的domain object比较稳定

测试！

用接口方便测试，可以自己写个Mock Object实现接口测试。

建议去翻翻论坛的老贴子，有很多讨论这个问题的。

interface主要是方便测试和解耦……

接口不稳定是因为设计期的问题

之后因为需求变动带来的接口变化不能归咎于面向接口设计的思想不好

我觉得使用接口，能使程序的设计看上去更清晰

我和Uranus目前正在为跳出我们老师所教的“MVC的”架构而努力，目前很明确的一点就是面向结构编程，理解的好处有三：
1、解耦合
2、设计良好的接口可提高多人协作开发的效率
3、便于测试，提高代码质量

我们在领域对象和DAO层的设计上实在是没有经验，今后还望各位多加指导

我并没有说面向接口设计的思想不好啊，可能是误会我的意思了，偶只是发发牢骚，嘿嘿