三层模式中如何分开业务和数据层

  • 格式:rtf
  • 大小:44.74 KB
  • 文档页数:2

三层模式中如何分开业务和数据层.txt成熟不是心变老,而是眼泪在眼里打转却还保持微笑。

把一切平凡的事做好既不平凡,把一切简单的事做对既不简单。

三层模式中如何分开业务和数据层?华软论坛 2001-12-08 15:51:53 在软件工程/管理 / 开发方法版提问
如果用“界面,业务对象,数据对象,数据库”模型进行开发,如果数据库中增加一个字段,是否要修改这些对象和界面、数据库?
是否有一个解决方法?问题点数:0、回复次数:11
1 楼回复于 2001-12-18 16:42:34 得分 0
这问题提得不错
2 楼回复于 2001-12-19 11:33:29 得分 0
不一定
如果模型已经成型,那是属于修改问题
如果模型已经未成型,那是成型问题
3 楼回复于 2001-12-19 12:24:27 得分 0
从广义上讲,增加一个字段,界面,业务对象,数据对象都会修改.但落实到具体对象上,就不一定是修改,而有可以是增加.
对一个系统来说,如果发生变化时,只是增加新的对象或代码,就可以称为好的系统.而不一定是不动代码.
对于某些类型的应用,采用XML+XSL也许会使你增加字段时,不用修改界面,业务对象,甚至于数据对象.
4 楼回复于 2001-12-19 17:06:53 得分 0
:mycode(不写代码)
GOOD!
5 楼回复于 2001-12-21 12:22:07 得分 0
我们曾经设想过一种设计方法,对象的属性可以动态加载,相对应的约束通过预定义的规则来解释。

在数据处理、界面显示、查询分析时,同样应用一些预定义的规则,再通过一系列我们自己开发的辅助工具完成大部分代码的生成工作,这样程序员需要做的工作只是写业务逻辑。

只是这样做有一个很大的问题,所有的数据都是动态的,运行时刻的错误就很难跟踪。

这需要在灵活性和易维护性方面做出权衡。

MYCODE说得不错,需求发生变化时,如果变化能够局限在一个小的模块或一个子系统内,设计就算是好的设计,不能希望在需求发生变化时,改动只有一点点,甚至只是一个参数的变动。

这不是从技术上不可行,是综合考虑设计、实现成本之后的折衷。

6 楼回复于 2001-12-22 10:37:44 得分 0
一个比较好的设计应该可以把这种后台数据的变化的影响面所见到尽可能小,但实际上,从一般的广义上讲,再小的修改也需要修改所有与这个数据相关的设计和编码。

除非这个数据具有一定的特殊性,比如说:一个商品的价格原来是采用人民币标注的,现在增加一个美元标注,这个时候,就不一定需要作所有的修改了,因为这虽然影响了所有显示商品的相关设计,但在编码上也许只需要修改有关面向国外的编码,而面向华人的编码和设计就完全可以不做修改。

其实,一般来说,这种数据库的变化应该属于需求变更,这种变更势必要影响到所有的分析、设计、编码,以及测试的,是不可避免的非常大的变化。

如果这种设计变更是因为当初没能明确的领会用户的需求造成的设计错误,那么,他也会影响设计、编码和测试,也是一个比较大的变动,这时候,项目组应该考虑增强一下评审和检查的措施,以避免再次发生同类错误。

7 楼回复于 2001-12-26 15:13:13 得分 0
我想这种情况可以区别对待,把数据分成业务特有的数据和业务共同的数据,分别建立表,这样一来应该可以提高软件的灵活性,不至于需求一改,程序也要跟着改.
8 楼回复于 2001-12-28 14:56:11 得分 0
就顶楼的增加字段的问题来说,我认为一个好的系统设计是这样的——数据库肯定是要动的;中间层肯定是不动的;界面可动可不动。

——当然所谓的动或不动是以是否需要修改源码为准的。

非常赞同uwind()的说法,我现在也在尝试一种与你们的设计极为相似的系统设计:代码里面出现的对象不包含任何的与业务相关的属性,而全部在对象实例中动态加载;业务逻辑由文本描述控制,相当于你说的预定义规则吧;最终程序员的任务只是利用自己写的管理工具增加或修改属性(数据)和函数(规则)的文本描述而已,程序代码的修改量达到最小(最有可能的修改是针对特定数据库产品做性能调整而进行的)。

简单地说,我们的设计原则是把能从程序里拿出来的东西都拿出来放在文本里,做一个极端的假设:所有的东西都拿出来了,那自然不用修改程序了。

所以中间层是根本不用改的,因为它全是自己写的,并且不必有直观的表现形式;数据库因为不是自己的,它动不动不关我们的事:);而界面呢,看用户的要求了,如果要求不是很高,可以用程序自动生成的(可能比较规则、呆板),如果用户要求好看一些就要改程序了,所以界面是可动可不动的。

uwind()提到“综合考虑设计、实现成本”的问题,我想如果真能实现(或者能实现百分之八九十)那样的设计目标的话,无论对哪种类似的系统都是通用的了,可重用性的提高应该可以节省其它类似系统的开发成本,所以我觉得这样做还是值得的。

希望有机会再听听uwind()的见解。

9 楼回复于 2001-12-29 09:54:05 得分 0
灵活性很高的话,用在实时系统里有可能会有效率的不足,因为几乎相当于完成了一部分解释器的功能。

还有,规则部件的建立可能还是需要更换的,有没有人建立子编绎系统,通过类虚拟机的方法来实现一些额外的逻辑功能。

另外,不知uwind和dq是否做过相应性能的对比和测试,有的话,能列出来的话就更好了!
10 楼回复于 2001-12-29 09:57:11 得分 0
to uwind() & dq(独轻)
首先要肯定的是这是一个好办法,或许XML能帮助你实现,但是,除了你说的“运行时刻的错误就很难跟踪”外,效率更是一个大问题。