我算是糊涂了
没有任何概念比计算机中的概念要模糊了
有时候,英文是一个意思,被人翻译后又是一个意思
比如我们常说的三层定义
第一种通俗的理解是
表示层就是像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,总要解决一个问题,那就是,当业务对象发生变化时,该如何去保持其数据存储的同步表现呢,怎样才让两者更离散一些,以解决后续维护带来的问题呢?
希望高手指点
没有任何概念比计算机中的概念要模糊了
有时候,英文是一个意思,被人翻译后又是一个意思
比如我们常说的三层定义
第一种通俗的理解是
表示层就是像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,总要解决一个问题,那就是,当业务对象发生变化时,该如何去保持其数据存储的同步表现呢,怎样才让两者更离散一些,以解决后续维护带来的问题呢?
希望高手指点
