贵阳市西商业街在哪儿:关于多层架构?

业务层:处理表示层的需求,并将数据层的虚数据实体化.
数据层:提供给业务层的虚数据.
表示层:把用户的需求展示出来.

最早的程序是不分层的,比如早期的批处理系统,只要编写操作某些文件格式的程序.
后来,随着客户机/服务器系统的出现,分层的概念就明显了,这样的系统是两层结构,客户端包含界面也包含应用代码.服务器端是数据库.但领域逻辑复杂并且易变时,这样做会有很多缺点,冗余代码,不利于重用,不利于分工等等.
再后来,面向对象的编程序的思想普及了,面向对象为领域逻辑问题找到了答案,转到三层架构的系统,在这中种方式下,表现层实现用户界面,中间层实现业务逻辑,在数据源层存取数据,这种方式可以将复杂的领域逻辑从界面中抽离出来，用对象加以建模和组织。
注意：三层结构不是物理的分层，客户机/服务器是两层的结构，它是物理的分层，客户机在一台台式机器上，服务器端是一台服务器，而三层机构无需把不同层次放到不同的计算机上运行，独立出来的领域逻辑层无需放到独立的计算机上，如果数据库在本地，也可以在一台机器上运行三层系统。
具体如何分离取决于系统的复杂度，从数据库中读取数据并将其在界面上显示，可能在一个过程中完成，但仍然存在三个层次，可能在这里只是把三个层的行为放到三个子程序中。如果系统稍微复杂一些，就可以把三层做成三个类，依此类推。但至少切记一定要进行某种形式的分离，至少在致程序级。
领域逻辑可以进一步分层，形成多层结构。

我算是糊涂了
没有任何概念比计算机中的概念要模糊了
有时候,英文是一个意思,被人翻译后又是一个意思
比如我们常说的三层定义

第一种通俗的理解是
表示层就是像WINFORM或WEBFORM等
业务逻辑层:这个东东是什么呢,做什么用呢?我开始的理解是那些DLL
数据存取层:就是数据库部分了.

但是第一种理解对于我来说,我觉得不太妥,具体有什么不太妥,也不知道.
无知者无畏,反正我也没有科班或正式的去学过三层体系,所以,不怕大家笑话,我就胡说八道几句吧
第二种理解是我最近想的
表示层是指界面部分,例如WINFORM,例如WEBFORM,或者其他一切用于呈现数据外观的东东
业务逻辑层:这一部分是我以前最糊涂的了,不过,最近接触了一点ORM的概念受了点启发,有了一点点理解
我们可不可以这样想,三层体系就是把数据的存储,数据的表示和数据的规则分离,这样一看,所谓业务逻辑(这个字暴生辟呀),就是指数据的规则,也就是说,数据的有效性等等.
至于数据存取层,这一部分,容易理解的多了,就是指用于直接读取,存储数据的部分.

我想,这样说,太生硬,摸不着看不见,但是下面的例子是做过ASP.NET的都遇到过的吧.
举个例子来说.
有一个表CUSTOMER,你要负责将此表内容呈见给浏览者.同时,提供另一个界面给数据管理者管理数据.
呈现给浏览者的数据是一个WEBFORM形式,呈现给数据管理者的是一个WINFORM形式.
不管怎么说,在表示层部分,这个数据使用了截然不同的两种表现形式.
但是数据来自何方呢?直接从数据库提取然后就显示吗?可能不行,对于WEBFORM的界面来说,你可能需要对数据进行一些加工.比如,把数据中的客户的LASTNAME和FIRSTNAME合并等.更有可能,对于管理数据的人来说,你需要处理一下录入的数据,验证一下这些数据是否合乎一些规则,比如,性别必需为男/女,比如,年龄不能大于20,有了这种需要,就意思着你不是需要从数据介质中提取的原始数据,或者你不是直接把录入的原始数据存入到数据介质中.你需要一个对数据进行验证,加工,变形的过程.所以,我想,业务逻辑层处理的就是这部分?

而数据存取层呢,一提到他我们就以为是关系数据库.其实不然,数据存取层是存取数据库/XML数据/其他任何可访问数据的代码.说到这些,微软的DAAB简化的就是数据存取层了.
以前我们要做一个数据存取层,就要建连接,建COMMAND,建一堆东东,然后还得记着统统关掉,及时释放.现在,DAAB简化了这部分的工作,使数据库的连接,查询,关闭自动化.
但DAAB取代不了数据存取层,因为它是抽像的,对应于每一个具体的实用(例如一个表),你必须去写一个具体的数据存取层.
另外,看了ORM外,我还有一个感想,以前,我做的东东里,都是先建好数据库,然后再去写代码.写得很乏味,后来,用起CODESMITH来自动生成.CODESMITH用起来很好.可是,看了ORM,大家都认为数据库是ORM的附加产物.也就是说不是由D到O,而该由O到D.这与我之前的过程恰恰相反.但仔细想想,确实该由O到D.
为什么呢?做过由数据库生成数据访问层的人都会有一个问题,就是,如果以后需要改动数据库中的一个字段,比如加入一个字段,删除一个字段,将会引发一连串的改动,包括会改动到涉及此字段的数据存储类以及业务逻辑类,改起来,很容易遗漏.
假如按上面的三层理解法,我们可以认为数据对象是中心.业务逻辑对其进行修饰及验证,一方面它又被呈现,一方面它又被持久化.因此,我们可以先去设计业务逻辑层(就是表示对象的了),例如上面的例子:
我们先建立名为CUSTOMER的对象.为其定义若干个属性,每一个属性表示CUSTOMER的一个字段.然后再为此CUSTOMER建立数据存取层.至于数据库,我想,有没有可能直接由CUSTOMER类的定义生成呢?

如果这样,似乎更符合自然规律,想想,我们建立CUSTOMER对象,先用类表示出此对象.为其添加属性,为其添加行为,然后,再生成此对象的持久形式.是不是很理想呢?

当然,以上是我的理解.我至今仍不清楚真正的三层究竟该如何定义.
我也不清楚ORM跟我第二种理解究竟有多大偏差.
更为重要的是,我迫切的想知道,有没有一种从O(对象)到D(数据)的开发方法.因为,业务对象和数据库联系实在太紧了
不管是由D到O还是由O到D,总要解决一个问题,那就是,当业务对象发生变化时,该如何去保持其数据存储的同步表现呢,怎样才让两者更离散一些,以解决后续维护带来的问题呢?

希望高手指点