有一系统用ado+socket三层方式
服务器端：Ado--sqlserver
客户端：socket连接方式
问：
1.当客户端需要查询或更新数据时，在客户端的clientdataset的commandtext
里写入语句，让服务器端去执行，是否合理？
2.当需要查询一个数据量较大的数据库时，采用select top 10000（为查询最大数，用户设置） * from table
然后，getnextpacket这样，是否合理？
3.服务器采用存储过程的分页方法，然后客户端调用服务器方法这样取得分段
数据，是否合理？
4.服务器端与客户端在设计时需要注意什么（就是大部分公司都这么做）？
1，不好，业务处理最好放在中间层或数据库，存储过程比中间层好，易于修改维护；当然这里还有衡量实现的复杂程度和性能要求
3比2好
4，注意数据传递要少，内存占用要少，事务处理要尽量短
1)这样做不好！将SQL语句封装在数据存取层就行了，尽量避免SQL散布到系统的各个角落。同时也不用所有的开发者都是SQL高手。。。
2）如果客户端所查询的记录数不大，那就尽量将记录数减少。（当然有某些客户喜欢一个屏幕显示几千条记录的喜好）如果客户数量不多，10000条记录还可以，如果客户端访问量大的时候，就不好了。
3）对于数据库存取比较频繁的情况下，尽量少用耗时的存储过程。
4）清楚了解到系统的非功能需求（如客户的访问量、数据量、扩展伸缩、性能等），根据情况来设计系统。一般来说：
A）网络传输。大量的客户访问，对服务器和网络是一种压力。所以尽量减少网络上的数据传输，例如减少连接次数，减少一次所传送的数据等。
B）尽量使用多层开发。
一个系统就象人一样，有青蛙恐龙，也有帅哥靓妹。如何将一个系统雕琢成帅哥靓妹，更多的是用心+经验+技术，不同的客户需求，不同的应用环境都有着不同的思量和测重点，是一种挑战。
个人建议： Martin Fowler 是一位实践家，一位大师，阅读他的作量，对你的开发会有很大帮助的。
软件开发方面《重构》、《企业应用架构模式》两书非常有帮助。
软件分析方面《分析模式》一书也很有帮助。
1.当客户端需要查询或更新数据时，在客户端的clientdataset的commandtext
里写入语句，让服务器端去执行，是否合理？
实际上灵活性不好。还是没有达到易维护.
2.当需要查询一个数据量较大的数据库时，采用select top 10000（为查询最大数，用户设置） * from table
然后，getnextpacket这样，是否合理？
delphi现在默认的就是无状态对象。但是可以通过Code去实现有状态的对象。用户在几秒钟是无法查看1000条记录的。
4.服务器端与客户端在设计时需要注意什么（就是大部分公司都这么做）？
无论是C/S,还是B/S，到当前的分布式我想应该从两方面去考虑。效率，维护，稳定。
对用户来说。不管你的软件使用了什么新技术。用户只求一个系统稳定。
对于海量的数据，用户是不可能要知道所有的数据的，因此，用分页处理并不是好办法。
你应该只返回客户感兴趣的那部分数据，解决办法就是让用户定制返回数据的条件。
我建议你这样做：
在App Server中定制一个方法：
function QueryXXXXXDatas(const SQL: widestring; var Datas : OleVariant) : HResult;
begin
ADODataset.CommandText := SQL;//这里的SQL就是你的用户在客户端定制条件生成的
ADODataSet.Open;
DataSetProvider.DataSet := ADODataSet;
Datas := DataSetProvider.data;
ADODataSet.Close;
end;
然后，在客户端：
var
Data : OleVariant;
begin
AppServer.QueryXXXXXDatas(SQL, Data);
ClientDataSet.Data := Data;
ClientDataSet.Open;
然后，你想干什么就干什么。
记住：三层中最重要的是逻辑层，而且要体现OO思想。
所以，最好不要把CDS直接连到AppServer的Provider上面。那样，只是多跑了一段路，不能算作是三层。而且这样做的话，如果以后项目要升级，或是业务有变动，会改死你的。
表现(客户端)与逻辑(AppServer)的通信应该是表现调用逻辑对象的服务来实现，即是客户端调用AppServer中的对象方法。在App Server中，通过公布与客户端交互的接口，并且把数据库存取操作封装在业务对象中，这样的这现方式比你直接连上去要清析得多，以后你的项目有变化，你改也好改，一般只改逻辑对象的实现就可以了。
我想对于程序员来说,抽象的目的是用更少的代码完成更多的功能,
同时使程序更易于编写和扩展,而Borland所做的许多工作正是为了这个目的
学会使用系统所提供的一些类和对象,将使问题变的更简单
系统提供的东西可能并不十分合适,有时候还需要一些修改和扩展
将问题分类,对每一类问题,用同一种方法来解决
多层结构速度慢的原因主要有三：1 大数据量网络传输 2 数据在层次间编组 3 Com+对象创建，
而最后一点无法改变，前两点优化则会有很大效果。对于大量取得数据操作，可由两法优化，A 每次
取一定数量数据例如1000，B 不通过编组方式取数（以上实现方法详见李维老师的书），对于大量
数据更新操作，个人实践经验不采用DataSetProvider的机制自动提交，而改为手动提交，甚至手动
语句提交，速度绝对有进步（相差两倍以上）。优化主要找到速度瓶颈存在何处数据库还是中间层
还是客户端，是运算还是数据，便可以针对关键问题解决之，这其中还是有很多技巧的，优化的过
程有不少乐趣哦，我曾经开发过的统计系统就在优化后速度提高了两倍以上。
Client:TSocketConnection 和Server: Scktsrvr关系----压缩数据传输
一直用SocketConnection和服务端的传输数据在三层数据库中，从来没有注意到它们之间的数据传输，只是想着，管它了，网络的事，前段时间在Delphi中的Demos中发现Demos\Midas\Intrcpt.dpr例子，呵呵，再看了半天的VCL发现可以将Client端发送的给Server的数据，和Server发送给Client的数据是可以进行压缩的。呵呵，不敢藏私，Share给大家。
1: 准备工作,先delphi光盘中的\info\extras\zlib\zlib.pas进行编绎，然后copy 到lib路径中，因为要压缩数据，必须要有压缩功能，这个delphi已经自带，它是基于流的方式对接口IDataBlock(TDataBlock实现，其实就是对TMemoryStream的操作)数据进行压缩和解压的。做了这个后，才能进行下面的工作。
2: Open \Demos\Midas\Intrcpt\Intrcpt.dpr
complier....(如没有做第一步，嘿嘿...)
生成Intrcpt.dll
将Intrcpt.dll copy to System directory,或者你的程序下面。
注册它：regsrvr32 Intrcpt.dll (为什么，这个嘛...)
记住Intrcpt.dpr的那个GUID,你也可以自己重新生成一个(按Shift+Ctrl+G)
3: Server:
Open scktsrvr.exe，相信各位都很熟悉那界面，端口(TListbox)，Thread Cache Size(TEdit), GUID(TEdit),好，我们要做的事，就是将注册的Intrcpt.dll那个GUID填到这个GUID(TEdit)框框中，
只需填自己程序的的那个端口的GUID啊，别乱填，如果有别人用这个程序，出了什么，别找我。OK,Apply.
Client:
你写的程序中肯定有TSocketConnection,它有个属性InterceptGUID: string;好了，将Intrcpt.dll的GUID填上去，它是跟Server中的一样的。OK.还有别忘了，Regsrvr32 intrcpt.dll 在你的客户端。不然，程序虽不会raise,但是Server传过来的数据是压缩的....
讲讲原理不，打字太慢了，过段再写。
scktsrvr.exe其实是一堆TServerSocket,一个端口代表了一个TServerSocket,每个TServerSocket是基于多线程方式与客户端进行数据交换。它写了个TServerClientThread(在服务端中的客户端)的扩展
,多加了对客户端数据接收的管理解析，还有ActivityDateTime,GUID，一般不管它。但是我们用到的压缩只是跟这个GUID有关，其它费话少说。
Server接受一个Client连接,则加一个TServerClientThread到本地中，用来监控Client Read 和Close事件，所以Server中的scktsrvr中我们只要了解了TServerClientThread动作方式就行了。
(
题外话：Server Socket中有客户端连接后，记录ClientSocket.Handle,并且将根据这个Handle产生一个TServerClientWinSocket对象加入到Connections(TList)对象中,当任何对这个Client的动作也就是说Server 发送和接收数据都是根据这个Client Handle来进行的，相应的ServerSocket中的Connections中的ClientSocket也发生相应的变化。
)
有两个类跟这个TServerClientThread(实现ISendDataBlock接口)有关
1: TDataBlockInterpreter(对发送过来的数据进行解析InterpretData(Data: IDataBlock))
解析数据（水平有限，对它真是还是一知半解，有错请指出)
接口类IDataBlock,由TDataBlock通过TMemoryStream的读写来实现，其中Signature是其主要标识，说明这个IDataBlock的数据类型 ，TDataBlockInterpreter根据Signature来对应进行相应的调用， 如：
Client端连接后，在Server要运行应用服务器(Application Server),
Client端需要得到ServerName 列表,
Client端得到Server 的DataBroker的列表，
Client端断开连接后，Server要Close应用服务器(Application Server),
Client和Server的数据交换，也是由它来解析。
所以这个IDataBlock的数据很重要，而我们的压缩和解压就是针对于它，但是TDataBlockInterpreter是得到Data才对它解析，因而我们要在Send 和Recv 之前对它解压和压缩。这个任务在TSocketTransport身上。
2: TSocketTransport;(数据进行发送和接收, 实现ITransport接口)
Server端:
在Server端,TSocketTransport其实就是一个用来管理对ClientSocket实例，它将ClientSocket.Handle生成一个对象后，ClientSocket发送和接收过来的Data，在发送Data之前,它将调用InterceptOutgoing(Data: IDataBlock)函数，这个函数的功能是:
如果InterceptGUID <> ''，那么它将根据这个GUID生成一个COM(Obj)对象，Obj.DataOut(Data: IDataBlock),也就是我们注册的那个压缩的DLL中的那个压缩函数，将压缩过后的Data再发送出去。这就完成compress and send Data.(我试过那个压缩功能，压缩比大概是1/9,像zip压缩比差不多).
由客户端传过来的数据调用InterceptIncoming(Data: IDataBlock)函数，这就不多说了，Data := 解压后的Data. 压缩和解压过后的Data交由TDataBlockInterpreter去解析，完成一次数据交换。
Client端：
说完Server端，客户端的道理也是差不多的。唯一不同的是Server端中不调用ITransport.SetConnected()方法，因为它是根据ClientSocket.Handle生成的对象，也就是它是已经连接的对象,而Client端的TSocktConnection调用Connected := True时，其实就是调用ITransport.SetConnect将一个ClientSocket连接到Server端中的TServerSocket中，然后TServerSocket根据这个ClientSocket.Handle生成了一个TServerClientThread对象保存在本地中，开始对这个ClientSocket的监控(FD_Read, FD_Close消息事件).
注：
IDataBlock由TDataBlock实现，主要是管理TMemoryStream来存放数据
ITransport由TSocketTransport实现，主要是用TClientSocket来连接TServerSocket,并和它进行交换数据。
ISendDataBlock在Scktsrvr.exe中由TServerClientThread实现，通过TSocketTransport来发送数据.
说了这么多，想必各们很明白了吧。：）
这个现实点，我测试过了，效果比dcom差点，相比socket要快多了
1、因为建立COM+对像是比较费时的，要尽早建立COM+对像，然后存到一个变量中，以便随后使用
2、事务管理越晚发生越好，且执行完后立刻调用SETCOMPLETE/SETABORT释放资源
3、客户端要采用少量多次的办法存取数据
4、正确设定一些存取组件的属性，如：CURSOR LOCATION，CURSOR TYPE等。