一个三层架构的问题!(虽然分少但这已经是所有的分了,请各位大哥帮帮忙,小弟先谢谢了) ( 积分: 40 )

  • 主题发起人 主题发起人 新来的菜鸟
  • 开始时间 开始时间

新来的菜鸟

Unregistered / Unconfirmed
GUEST, unregistred user!
我想做一个三层架构,也就是用一个服务层连接数据库,然后用多个客户端连接服务层!
我的服务层是用一个ADOConnection,一个ADOQuery,一个DataSetProvider
客户端用的是一个DCOMConnection,一个ClientDataSet,一个DataSource,一个DBGrid

现在我有几个问题想不通,请各位大哥帮忙解答一下谢谢!
第一.在客户端对数据进行添加,删除,修改的时候一般是用
ClientDataSet1.Close;
ClientDataSet1.CommandText:='INSERT INTO test2(testid,test) VALUES (1,''111'')';
ClientDataSet1.Open;
这样的方式还是直接用
ClientDataSet1.ApplyUpdates(0) 来修改数据,那一种更为稳妥些,也就是当多用户执行的时候不容易丢包不会出现添加不成功或删除不成功的情况,还有如果出现添加不成功或删除不成功的情况如何写他的处理事件让他执行回滚!

第二.如果服务端只用一个ADOConnection,一个ADOQuery,一个DataSetProvider,而多个客户端进行数据处理的时候会不会相互干扰,会不会出现丢包的现象!如果出现相互干扰丢包的现象又该如何写它的处理事件!

第三,就是在服务端需不需要写一些东西来管理多客户进行数据查询的时候处理异常的情况,该如何写!(在服务端不会就只放一个ADOConnection,一个ADOQuery,一个DataSetProvider这三个东西连上数据库后就什么都不用管了吧,呵呵)

第四,我的目的就是想要一个非常稳定的连接方式不会出现添加不成功或删除不成功之类的现象!

呵,各位大哥,我是第一次接触三层三层架构,所以什么也不懂请各位大哥帮帮小弟,小弟万分感谢!
 
最近写了几个三层的,使用ClientDataset,传递Delta 到DataSetProvider,一切由DataSetProvider来处理.其事件已相当的多,完成可以了. 你可以看一看李维的 <分布式开发系统篇有一些说明> 和 <面象对象编程思想>一说也有介绍.
 
to ZBJ2001_KF
呵,能不能给些具体的例子来看看,如何对表进行添加,删除,修改!当对表的异动发生异常的时候如何写事件进行处理让他回滚!麻烦您了,谢谢!
 
随便你怎么写,
做成事务就没事了。
 
在ClientDataSet1.CommandText中 显式添加事务语句:
BEGIN TRANSACTION
你的INSERT OR DELETE OR UPDATE ....
COMMIT TRANSACTION
if @@ERROR <> 0
begin
ROLLBACK TRANSACTION
RETURN
end

永远不会因为事务问题而出错.
如果用ADO的隐性事务,哪么只有在提交的SQL中语法出错时,才能回滚,若是其它完整性错误时,ADO是不能全部回滚的,所以用显式事务语句.(在三层中若用 Adoconnection1.BeginTrans 来控制是不行的 )
 
to jettop
非常感谢,那在服务端要写什么事物处理吗?怎么写?
 
各位大哥,能不能给个服务端和客户端完整的代码来看看,最好是sql server 数据库的,我的Email是yangzongling18@163.com 麻烦各位大哥了,谢谢!
 
首先使用clientdataset显示数据是合理的,但是用它处理数据(增删改)都是不合理的。一旦遇到事务问题很难解决。
jettop写的解决方案是治标的办法,如果你的语句很复杂,你的代码就会很难读。
这里我推荐借鉴java的做法,将客户端需要操作的数据组织为xml传递给服务器,由中间层控制事务来处理。
客户端应该只负责显示和用户输入,所有的校验、保存等工作都应该由中间层来处理。
如果你的事务逻辑由客户端决定,也就意味着你的大部分业务逻辑都由客户端决定了,那么为什么还要用三层呢? 你的中间层就变成了一个客户端到服务器的数据访问代理了,失去了使用多层的意义
 
to ball_cao
呵,谢谢您的指导,我大概明白的的意思了!你的意思是说所有的事物处理都交由中间层来处理,而客户端只是简单的下sql而已,现在我的服务层是用一个ADOConnection,一个ADOQuery,一个DataSetProvider来建立的,该如何在里面写事务处理呢?能不能给个服务端完整的例子呢?万分感谢,谢谢!
 
是个问题呀,APPSERVER有没有这种方法,就是事务开始,多少时间没提交就回滚。因为公网不稳定。
 
看来你没有明白我的意思
客户端应该完全没有语句才对!
客户端应该从服务层申请需要显示的内容,然后只负责显示。
如果用户有操作,你也是通过客户端将用户操作后的数据发给中间层,由中间层保存到数据库。至于这个保存是否需要事务,是由中间层来确定的,客户端应该完全不关心事务问题。
DataSetProvider的方式也不够理想,用DataSetProvider会保持一个从客户端到应用服务器到数据库的连接。而这样的连接是很消耗资源且不稳定的。既然采用了多层结构,中间层和客户端之间应该实现无状态。否则你的服务分布起来很困难,更遑论动态负载平衡等等问题了。
最后给个笼统的建议
如果你不能做到完全的无状态,至少要尽量的朝这个方向努力,否则以后将面临非常多的问题
 
ADOconnection本身就有方法开始事务,结束事务
 
在服务器端定义一个方法
procedure TServerHrRM.SysExecSqlWithTran(const S1, S2, S3: WideString;
var Result, ErrorStr: OleVariant);
begin
with AdoConnection1 do
begin
BeginTrans;
try
if Trim(S1) <> '' then
Execute(S1);
if Trim(S2) <> '' then
Execute(S2);
if Trim(S3) <> '' then
Execute(S3);
CommitTrans;
except
on E: Exception do
begin
RollbackTrans;
Result := -1;
ErrorStr := '执行SQL语句时发生错误!' + #10#13
+ '信息:' + E.Message;
end;
end;
end;
end;
在客户端用
DCOMConnection.AppServer.SysExecSqlWithTran
跟用一般的函数一样
这可以应付一些简单的事务处理,复杂的我一般在SQL的存储过程里完成.

我也刚开始搞三层,很多时候是用两层的思路来处理
正如ball_cao说的"你的中间层就变成了一个客户端到服务器的数据访问代理了,失去了使用多层的意义 "
呵呵,没办法.水平有限正在补课.
 
很多人觉得用采用三层结构就是简单地理解把所有的处理放在中间层,我个人不同意这种做法,首先我们考虑到的每个处理方法是不是应该这样做,值不值得这样做.如果一个简单的处理方法在客户端两三个语句就可以搞定,而你一定要在中间层写上几十行代码,而这几十行代码你还要考虑系统的稳定性,不知这一味地追求这种思路的人有什么感想.
 
to leonmtv
如果你的代码不需要重构和维护 怎么写都可以
但是如果你需要维护的时候发现有的语句在客户端,有的语句在服务器 那你就真的会知道为什么前期要强调分离了。
我强调不要在客户端写语句的一个重要原因是 如果你在客户端写了第一个语句很快你就会想要在客户端写事务 而等你在客户端操作问题以后你就开始走向一个无法维护的泥沼(注意是“无法维护”,不是“难以维护”)而等你想要再走出这个泥沼的时候你就会发现 只有客户端完全没有数据库逻辑 你才能摆脱这些无法维护的事务问题。

用delphi的兄弟们可能不太研究别的语言 如果你注意一下java的主流框架或RoR就会发现 这些框架是提倡程序不要在客户端写数据逻辑的 为什么?一个是稳定性,一个是可维护性,一个是可测试性还有就是你的应用服务器的可伸缩性。
还是那句话 既然你用了多层 就好好用多层的特性 不要为了多层而多层。除非你做多层只是为了一个商业上的噱头
 
同意。
分层的目的是以后不管是自己还是他人便于维护系统。与其一开始工作量大(何止是工作量大)一些。为的是以后省去很多麻烦。省去很多维护费用。
分层的好处很多、很多。尤其是作大一些的系统,随着系统的开发,系统功能的堆积增加,若一味地把数据、业务逻辑以及界面混为一体。麻烦就会越来越大的。如果,客户要求你改变功能,那就更麻烦了。相反,分层很容易改动,系统功能很容易扩展等等好处。
如果,你要做一个单一的小系统,那就没有必要分层了。
 
多人接受答案了。
 
呵呵...我所强调的是部分不需要的,而不是所有.当然,在系统的设计当中,要根据不同的环境需求而定的,这可能跟各人的工作环境不同而论吧.如果把java的设计思想都搬都到delphi中,呵呵....那delphi就不叫delphi了.首先再声明一次:根据不同的环境需求而定的.
 

Similar threads

S
回复
0
查看
3K
SUNSTONE的Delphi笔记
S
S
回复
0
查看
2K
SUNSTONE的Delphi笔记
S
后退
顶部