UI 层和逻辑层大家的讨论使我明白在设计多层构造的程序时，层与层之间需要多用接口少用继承，但为何要用接口呢？例如逻辑层直接实例化一种数据访问层的类，然后调用数据访问层中对应的措施返回一种数据源不就可以了吗？这样做也不关接口什么事呀 在企业级程序开发中，一般出于并发的考虑，也许需要很好的可伸缩性(就是可以把一套程序的不一样构造层放在不一样的服务器上，我是这样理解的)，这样的话以 asp.net 的最简单的三层构造举例子，UI 层和逻辑层应当是放在同一台服务器上(我不懂得能不能把它们分到两台服务器中去)，我把它叫做[UI&逻辑服务器]，而数据访问层放在另一台服务器中，我把它叫做[数据访问服务器]，尚有一台是寄存数据库的服务器，这样 UI&逻辑服务器 与 数据访问服务器 中的程序也许就是 2(或以上)个人开发的，两台服务器间的通讯一般是用 WebService，这个我就不说了。按我上面说的，UI&逻辑服务器 中的程序应当是可以直接调用 数据访问服务器 中的类，这自身没什么问题，但到详细开发上时也许就会出问题了，例如 UI&逻辑服务器 中的程序开发人员甲在开始设计的时候需要调用一种 数据访问服务器 中的 GetData()的措施，但这个时候 数据访问服务器 中程序的开发人员乙并不懂得需要增长这个措施，那么甲的工作就继续不下去了，由于他的程序编译不了，假如这个时候甲定义了一种接口，然后在接口的定义中定义一种措施 GetData()，当然这个措施里什么代码都不用写(详细的实现是由乙来做的)，然后乙写的程序都需要继承甲定义的这个接口，当乙的程序在编译的时候就会被提醒哪些措施是必须被实现的，这样一来乙就随时都可以懂得甲需要哪些措施来返回数据了，这样做最起码的好处是不用甲总需要告诉乙需要加哪些措施，并且也不会由于乙对数据访问层程序的误修改(例如误删除了GetData()这个措施)导致 UI&逻辑层的程序运行不正常，由于假如删除了 GetData()的话，乙的程序是编译不了的。 因此我的结论就是接口在层与层之间的作用重要是上层(例如 UI&逻辑层)对下层(例如数据访问层)的某些限定，以便了开发，减少了不必要的沟通，也防止了某些出错的也许。不懂得这种理解与否对的，还请大虾指教需求分析的 20 条法则2009 年 08 月 27 日 星期四 下午 11:27-08-11 16:00需求分析的 20 条法则 邢学慧 ---对商业顾客来说，他们背面是成百上千个供应商，前面是成千上万个消费顾客。怎样运用软件管理错综...
