看了csdn上面的一个帖子(http://community.csdn.net/Expert/TopicView.asp?id=3589269)，大家的讨论使我明白在设计多层结构的程序时，层与层之间需要多用接口少用继承，但为什么要用接口呢？比如逻辑层直接实例化一个数据访问层的类，然后调用数据访问层中相应的方法返回一个数据源不就可以了吗？这样做也不关接口什么事呀
这个问题我想了好多天也没想通，这两天看了微软的一个WebCast(http://www.microsoft.com/china/msdn/events/webcasts/shared/webcast/episode.aspx?newsID=1242157)，了解了企业级程序开发的一些方法，似乎让我对上面这个问题明白了，但不知道是否正确，还请各位多多赐教！
在企业级程序开发中，一般出于并发的考虑，可能需要较好的可伸缩性(就是可以把一套程序的不同结构层放在不同的服务器上，我是这样理解的)，这样的话以asp.net的最简单的三层结构举例子，UI层和逻辑层应该是放在同一台服务器上(我不知道能不能把它们分到两台服务器中去)，我把它叫做[UI&逻辑服务器]，而数据访问层放在另一台服务器中，我把它叫做[数据访问服务器]，还有一台是存放数据库的服务器，这样 UI&逻辑服务器 与 数据访问服务器 中的程序可能就是2(或以上)个人开发的，两台服务器间的通讯一般是用WebService，这个我就不说了。按我上面说的，UI&逻辑服务器 中的程序应该是可以直接调用 数据访问服务器 中的类，这本身没什么问题，但到具体开发上时可能就会出问题了，比如 UI&逻辑服务器 中的程序开发人员甲在开始设计的时候需要调用一个 数据访问服务器 中的GetData()的方法，但这个时候 数据访问服务器 中程序的开发人员乙并不知道需要增加这个方法，那么甲的工作就继续不下去了，因为他的程序编译不了，假如这个时候甲定义了一个接口，然后在接口的定义中定义一个方法GetData()，当然这个方法里什么代码都不用写(具体的实现是由乙来做的)，然后乙写的程序都需要继承甲定义的这个接口，当乙的程序在编译的时候就会被提示哪些方法是必须被实现的，这样一来乙就随时都可以知道甲需要哪些方法来返回数据了，这样做最起码的好处是不用甲总需要告诉乙需要加哪些方法，而且也不会因为乙对数据访问层程序的误修改(比如误删除了GetData()这个方法)导致 UI&逻辑层的程序运行不正常，因为如果删除了GetData()的话，乙的程序是编译不了的。
所以我的结论就是接口在层与层之间的作用主要是上层(比如UI&逻辑层)对下层(比如数据访问层)的一些限定，方便了开发，减少了不必要的沟通，也防止了一些出错的可能。不知道这种理解是否正确，还请大虾指教
