讨论，关于三层，希望DFW的前辈们能参与，给大家上上课 (大家畅所欲言吧) (200分)

对三层我的疑问在于
1.多并发数的用户
2.大数量数据的提交.
个人认为在解决死锁什么的问题上.三层优于CS模式.
CS连接到后台数据库,尤其是用数据组件连接的.打开表后.好像是一直挂在数据库上的.
不知道对不对,请大家指正
等大家发言
 
各位：
我使用ASTA的控件来开发，那个控件的三层结构很好实现，不知道各位都用什么来开发的。
 
关于层的划分，我觉得这个东西没有什么呆板的规定，应该是根据实际需要罢了。
层越多，越复杂，但是更容易控制（可以控制的更精细，方式更多）。
其实就是在客户端程序的编写，我们也是体现了层的概念，常见的是把功能的实现和功能的调用完全分开，再使用一个协调对象来管理这两者。很多设计模式也涉及到了分层的思想。
总之，我觉得层只是一种思维方式，是一种合乎逻辑的划分。
 
到底有没有人真真正正的做过三层，而且运行良好？
欢迎大家踊跃发言！
 
运行良好的3层肯定是有，我做过，我不知道你所谓的良好是何种概念，但至少我认为是良好的，不过那都是花了极大的心血的。
在前面关于如何处理种种逻辑的东西也都有了，只是具体的实现问题。
若你问母鸡会不会下蛋，我会回答你会，但问我如何下的，那只有母鸡才知道了。
同样的，有些东西是只能意会不能言传的，即使是能，也不是3言2语就能说的明明白白的。
李的书也有说，论坛上也有讨论，兵分3家，家家有理，呵呵，你又怎么办呢。
做合适自己的才是最好的。
 
瘦客户端有它瘦的好处，不过在网络状况不太好的地方就有点。。。。
个人认为瘦客户端比较适合企业的局渔网，在跨网段的时候往往问题多多
 
这个问题真是令人困惑！
我现在所在公司做的三层结构，但是真令我心碎！搞得不伦不类！
为了“集中业务逻辑”,开了n多接口方法，传过去的数据是olevariant,到服务器端再解析--一个个字段拆开，根据条件处理，写起来烦死了！这样虽然能解决一点“业务逻辑”的问题，也会引起前后段不一致，表数据被服务器改了，前台要刷新，所以到处是.close;.open;刷新慢得要死！
还有，像有些问题处理起来要比两层复杂多了！比如：有些客户要求新增的时候取“单号”，单号放在一个表里维护，要和最后的单据数据提交放在一个事务里！"可麻烦坏了，因为我们的单据数据是有“业务逻辑”的，所以更新是由服务器来完成的，而tdatabase在服务器端，前台取单号写表不能和后台在一个事务里！想通过接口把事务引到前台都不行，因为delphi有bug!--还得改delphi的代码！
从控件的设计上来看，borland的多层还是面向数据集的，什么时候为我们考虑过“业务逻辑”，而且控件也不成熟，好多bug,主从表更新也有问题，李维那本书上的“巢状数据更新”只能做一些简单的主从表操作，而且更新的时候，clientdataset的状态变化有错误！主从表不能做一些较复杂的操作。所以我觉得，至少在目前做项目还是用两层好一点！至少比较稳定！
其实，“业务逻辑”真的一定要用三层来解决吗？在两层里面用存储过程和触发器也能解决，业务逻辑变了我也不用分发客户端，改存储过程的脚本就可以了，而且连编译也不需要，岂不是更“帅”！---只是会降低一点数据库服务器的速度！[:D]
当然，三层也有它的好处，就是可以给个接口给别人调用！别人不用管具体实现，不过这种我们现在用得还不多，就那财务软件来说吧，金碟和用友什么时候公布过自己的口给别人调用的！还是我们自己来揣摩他的数据库结构来写导入数据的！
 
vmao,
你说的现象是由于设计不良造成的.
为了“集中业务逻辑”,开了n多接口方法，传过去的数据是olevariant,到服务器端再解析--一个个字段拆开，根据条件处理，写起来烦死了！这样虽然能解决一点“业务逻辑”的问题，也会引起前后段不一致，表数据被服务器改了，前台要刷新，所以到处是.close;.open;刷新慢得要死！
 
vmao,
你说的现象是由于设计不良造成的.
层间数据传输应该用data transfer object, 用olevariant或safearray是不好的做法.
事务的scope不可太长,对于长事务, 可用version或Optimistic Locking的方法解决.
基于dataset的模式做三层不合适, 容易带来性能问题. 象J2ee里就很少用dataset. 现在borland正在推ECO(BOLD), 这要好一点.
存储过程存在移植和维护扩展不方便的问题, 不适合做大架构.连oracle的新ADP(Application development platform)都是基于EJB的


 
我以前写的都是一些假三层，AppServer只是一堆控件，没有业务逻辑，要改成正统的三层的话，有点不知从何下手,感觉太麻烦，借此机会，听听课先
 
作了3年三层的东西，基本的理解是：
1、业务逻辑大部分放到中间层来完成
2、十分复杂的过程可以放到数据服务器
3、客户端基本上是界面部分
4、通过接口实现系统的鉴权和授权，应用服务器每次只打开客户对应的权限
5、尽量减少返回的数据集的大小
6、使用压缩传输，减少数据的传输量
7、复杂的调用使用接口来实现
 
to yyanghhong
能不能简单的介绍一下J2ee的三层思想？最好能说一下J2ee怎么实现的？
to HostingLian
“复杂的调用使用接口来实现”是什么意思？接口是不是说AppServer.XXX，如果这样的话，您是不是经常调用clientdataset.applyu...？
 
vmao说的“从控件的设计上来看，borland的多层还是面向数据集的”还是满有道理的，clientdataset给人的感觉确实是这样的，在客户端看来基本上就是直接操作数据库中的数据！
 
to HostingLian：
你说的使用压缩传输，减少数据的传输量不知道是怎么实现的，能说说吗？
 
zzjmail
就是在传输前把要传输的内容压缩，接受端收到后再解压缩还原
 
to wisenow：
有很多比较复杂的算法，我是使用接口来实现的。比如，鉴权，电信结算等。接口调用和clientdataset.applyupdata没有关系。但是一般客户端数据修改添加必须使用clientdataset.applyupdata。
to zzjmail：
压缩算法borland有现成的例子程序，你看一下例子目录midas/intrcpt的例子
 
gz~ 讨论的非常好
不过我不清楚的是这与ADO dbExpress这几种方式有关吗/？
 
我就是一直没有真正解决好三层的问题，所以一直使用二层来开发。
请问，除了DELPHI和CBUILDER之外，还有什么工具可以开发三层模式的软件？
 
楼上.三层更多的是一种上层的设计思想.最早是 MSF 提到的。 Borland Midas 是一个实现的FrameWork.我们自己当然也可以脱离这个东西来写三层了.归根到底是 COM组件的实现.
因为 Midas也是个COM对象的.
to 大家：
不知道大家怎么处理这个问题的：
客户端的一个操作可能需要占用很长时间,比如：数据查询.而往往是无法提前知道的,所以会很慢很慢的.大数据量的浏览和修改是不是不太适合用,或者需要是注意的一个问题.
如果和多线程结合起来,一个线程提前取下载辅助信息,一个线程（前台的数据编辑）来继续处理,是不是可以提高处理的速度呢？至少用户看上去不是死机的样子.
如果你起用了一个线程,但是在一定时间内没有返回结果,你可以丢弃这次的数据。

再比如：如果客户端是需要写数据（假设,需要很长很长的时间）,用线程可能也是无法节省这部分时间的,这样的情况,是不是就无法提高效率了呢？
......
 
to itren
“三层.归根到底是 COM组件的实现”，这个说法有些不对了，你可以撇开midas,但却不应该落在COM上，而应该是 服务器 + 通信(socket) + 客户端
 
您必须登录或注册才可回复。

Similar threads

不
Delphi的参数传递约定以及动态参数个数(转载笔记) - 不得闲
回复
0
查看
700
不得闲
不
不
ISO8583报文协议（转） - 不得闲
回复
0
查看
670
不得闲
不
S
[转]ClientDataSet加上TDataSetProvider的数据保存问题
回复
0
查看
3K
SUNSTONE的Delphi笔记
S
S
[原]Delphi2010中DataSnap高级技术(7)—TDSServerClass中Lifecycle生命周期三种属性说明
回复
0
查看
834
SUNSTONE的Delphi笔记
S
S
[转]ClientDataSet加上TDataSetProvider的数据保存问题
回复
0
查看
2K
SUNSTONE的Delphi笔记
S
顶部