关于企业应用层次间互交的问题(希望有经验的来讨论) ( 积分: 50 )

企业应用层次间互交的方式目前大概有两种风格：
1.对于实体对象，在各个层次间进行根据应用层次的范围分为VO(ValueObject)，DO(DataObject)等,
在不同的层次间使用不同的对象进行数据交换。
利：层次之间使用范围有限的对象进行耦合，解耦容易，且层次结构比较清晰分明
弊：当实体对象属性变化时，比如增加一个客户需要看到的数据，需要从界面层一直改到数据库层，
需要改动多个对象。

2.微软风格，使用Dataset方式，用DataSet做为层次间交换信息的公共对象，典型的例子是使用
DataSet映射表，然后将DataSet直接传到UI层，编辑以后再存到数据库中。
利：使用DataSet，在实体对象属性变化时，可以只改动DataSet的生成方式。
弊：使用一个对象把各个层次串了起来，耦合程度比较高
使用DataSet很可能会映射多个数据库表，这样，没有办法限制对象实现的范围，容易造成
烟囱式的软件，加大维护的难度。
大家看呢？你倾向于哪一种模式？

企业应用层次间互交的方式目前大概有两种风格：
1.对于实体对象，在各个层次间进行根据应用层次的范围分为VO(ValueObject)，DO(DataObject)等,
在不同的层次间使用不同的对象进行数据交换。
利：层次之间使用范围有限的对象进行耦合，解耦容易，且层次结构比较清晰分明
弊：当实体对象属性变化时，比如增加一个客户需要看到的数据，需要从界面层一直改到数据库层，
需要改动多个对象。

2.微软风格，使用Dataset方式，用DataSet做为层次间交换信息的公共对象，典型的例子是使用
DataSet映射表，然后将DataSet直接传到UI层，编辑以后再存到数据库中。
利：使用DataSet，在实体对象属性变化时，可以只改动DataSet的生成方式。
弊：使用一个对象把各个层次串了起来，耦合程度比较高
使用DataSet很可能会映射多个数据库表，这样，没有办法限制对象实现的范围，容易造成
烟囱式的软件，加大维护的难度。
大家看呢？你倾向于哪一种模式？

學習一下先

刚领悟OOP的朋友一定会选择第一种方式。
而我会倾向选择第二种方式，我的观点是：DataSet是一种复合数据类型，和List一样。
不要简单地把它看成一种对象，也不要死板地把它看成是数据库表的接口；它封装了动态变化的实体对象。
至于耦合度的高低，可能更大程度上决定于Server端的实现方式。

搞了几年两层，3层，N层，
搞来搞去， 说到底， 还是在传输层上， 把数据发来发去。
不管哪一个模式，其根本目的是为了， 平衡负荷，(让大家都干点活) 和各司其责，增加软件的可伸缩性 。
如果把这个目的没搞清楚， 就会适得其反， 我看过有些三层， 从数据库 或 其它底层协议取一些数据，中间件 不处理， 但是又重新编码(不透明转发) ， 客户端又解码，
像这种方案，不好维护，效率又低，三层何用？
我觉得TCP/IP 协议栈的分层方法，是很好很好的，值得去领悟。

建议都去看看 《企业应用架构模式》

楼主问的问题不是如何分层，而是问层与层之间如何进行交互。
我觉得z_cd说的有道理。TDataSet其实从DELPHI 3 开始就已经完全抽象化，很适合做数据接口。