我对N层架构间使用接口的理解

类别:.NET开发 点击:0 评论:0 推荐:

  看了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&逻辑层)对下层(比如数据访问层)的一些限定,方便了开发,减少了不必要的沟通,也防止了一些出错的可能。不知道这种理解是否正确,还请大虾指教

本文地址:http://com.8s8s.com/it/it41692.htm