三层结构怎么跟面向对象设计结合起来？

[zw]

业务逻辑层跟应用层之间交换的数据是一个数据集，如果引入面向对象设计方法，两层之间交换的数据应该是什么形式？

[lcgong]

不知老兄指的“业务逻辑层”和“应用层”指的具体是什么，目前这些次好像用乱了，:-)。
如果表示动态的描述，UML有协作图、顺序图、状态图以及活动图。
如果描述各层负责对外交互的[对象之间]在某个用例[表现关系]的话建议是用顺序图（或者协作图）。

[yihua_cai]

面向对象是一种方法论，而不仅仅只是一种程序设计技术。

面向对象技术可以应用于三层结构，也可以应用于别的结构。

举个例子：我们公司开发的软件结构也是三层结构：客户应用层（客户机）、业务逻辑层（应用服务器）、数据层（关系数据库）。现在我们要增加一个web服务器，那我们把客户机看成一个类，web服务器就继承于客户机，只是在客户机的基础上再封装一个Web接口就行了。这就是面向对象技术的应用。

[gfzhx]

我觉得不管是三层还是多层结构，和是否采用面向对象没有太多联系，你可以采用也可以不采用，但你会发现，面向对象的设计方法可以为你带来很多好处，你完全可以用面向对象的设计方法设计一套多层结构的架构来，具体的业务逻辑就是往架构上填上你的业务逻辑了就可以了，采用面向对象的语言就可以很方便的设计这套架构了。

记住，面向对象是一种思想，当你真正掌握了它以后你就会发现多层还是非多层都是很容易解决的问题了。

[hollysky]

关注

[AiWangji]

对象数据的交换可以用序列化方法来实现。

[gks_cn]

gz

[ozzzzzz]

你可以把交换的数据看成最小的对象 不要把数据作过分的封装 首先应该考虑数据端的执行效率问题 中间层和应用层在短期内改变升级的可能性要大的多 而且技术也进步快得多 而数据层的东西相对要严谨和稳定

[lcgong]

我简单的介绍一下我的经验（欢迎指正）：
首先，定义domain object，建立业务用例模型。然后确定系统用例模型。
在确定的每一个用例下进行模型分析，采用boundary-control-entity模式，建立分析模型，在这主要使用协作图和顺序图和类图。
在分析模型的基础上，设计设计模型(design model)，这时要考虑那三个层次的各自的责任（responsibility）和结构（structure），我主要分的是Windesk/Web/AppServ/DataService, windesk/web属于三层结构的表达层（或者client），appServ当然是第二层了，dataService也就是数据库设计了。在设计模型中,几乎都是class diagram，除了表达层（client tier），由于主要是面向事件的设计，故采用状态图表示各个交互元素的关系.

[yorgo]

交换的数据可以简单的看成recordset,不知这样解释是否理解

原来我也有这样的困惑，后来经过别人的指导得出这样的结论，细想一下，从数据库中取出的recordset本来就是一个数据集合，就是一个物件，可以在各层次之间传递了

[gfzhx]

我不建议使用recordset（你应该是用ADO吧），第一，使用有可能受到限制，在ADO中，你必须断开连接后才能把recordset传来传去。第二，使用时开发人员必须知道数据库中的表字段名，那假如不使用数据库呢（好像比较少），这样就不是很通用了。

问题就是看你采用什么语言开发了，如果是java问题就不是很大了，用对象搞定一切。

[catthunder]

做OO分析时可以不考虑具体的开发工具，但要是做设计时，就必须和具体的开发工具了。举个最简单的例子，你如果有个模版类，用C＋＋可以实现，但如果用其它工具的话，VB或Delphi等，你可能就非修改你设计了。
同样作三层设计时也是这样，如果设计出来的东西看上去很清晰，但是要程序员写代码却要很多费很多功夫，我觉得那不会是一个很好的设计。我觉得设计的一个要点就是能让代码清晰，易懂。如果设计时不关注写程序的实际情况，别的不说，那些程序员早就不干了。
lcgong(踏雪)，你有经验，能不能举个例子再详细点谈一下你作的设计？