大家来说说,中间层封装业务逻辑的心得(50分)

我现在也在尝试这种方式，因为可以把作界面层，业务层交给不同的人作。
我现在是用类封装了数据对象，里面封装了一些属性，以及跟访问数据的方法，
作界面的只需要知道这个类就行了。
比如：
TBase = class
private
FQuery: TADOQuery;
FID: Integer;
procedure SetID(const Value: Integer);
function GetEof: Boolean;
protected
FTableName: string;
procedure SetFieldValue;
virtual;
procedure GetDataFromTable;
virtual;
public
constructor Create;
virtual;
destructor Destroy;
override;
procedure Submit;
procedure First;
procedure Next;
procedure Prior;
procedure Last;
function Delete(const AID: Integer):Boolean;
virtual;
property ID: Integer read FID write SetID;
property Eof: Boolean read GetEof;
end;

TProduct = class(TBase)
private
FSpec: string;
FSotpMake: Boolean;
FPrice: string;
FUnits: string;
FMemo: string;
FName: string;
FSortID: string;
procedure SetMemo(const Value: string);
procedure SetName(const Value: string);
procedure SetPrice(const Value: string);
procedure SetSotpMake(const Value: Boolean);
procedure SetSpec(const Value: string);
procedure SetUnits(const Value: string);
procedure SetSortID(const Value: string);
protected
procedure SetFieldValue;
override;
procedure GetDataFromTable;
override;
public
constructor Create;
override;
destructor Destroy;
override;
property ID;
property Name: string read FName write SetName;
property Spec: string read FSpec write SetSpec;
property Units: string read FUnits write SetUnits;
property Price: string read FPrice write SetPrice;
property StopMake: Boolean read FSotpMake write SetSotpMake;
property Memo: string read FMemo write SetMemo;
property SortID: string read FSortID write SetSortID;
end;

Tbase是个基类，
Tproduct是产品类。
要访问一个产品内容，只需要创建一个Tproduct对象。 给出一个产品ID就可以了。
其属性Name对应于字段Name（名称），属性Spec对应于字段Spec（规格）。。。
Submit方法用了提交对数据的修改。
比如后台数据库觉得Name（名称）字段需要增加宽度，该了。
界面可以不动，因为对应它来讲TProduct类的Name属性没有变。
以上内容由于个人水平有限，请勿见笑！

<content><![CDATA[[brown]我是新手，看各位高手的解说。[/brown]]]></content>

[brown]我是新手，看各位高手的解说。[/brown]

我粗粗观摩过金碟K3的产品
是国内少见的设计较好的多层结构的例子
可以向金蝶要一个trial version 和二次开发文档
相信对理解组件化设计会有帮助

好像在国内没几套三层软件有真正把业务层封装在中间层吧，因为如果真的要做到封装在
中间层，对于一开始的逻辑设计要求就很高了，变成许多业务逻辑一开始就要正确并利
于扩充，除了一些比较有规律的系统，如电信、银行等非经常性变化的逻辑才行吧

那现在三层写成这个样子意义何在？
负载均衡算一个吧
可是又听说，一台应用服务器的客户连接不要过48，是李维书里的吧
48。。。一般企业用一个系统那里会超过这个数
C/S下48个客户端也不可能同时在全负荷运行吧，一个服务器配好点也就够了吧
三层，呵呵，说吧，用这个开发系统是为了与国际接轨吗？

谈一下我的粗略理解:
1.业务规则
我把数据库字段的not null ,maxvalue,minvalue,constraint等理解为"业务规则"
BDE可以很好地把这些规则自动引入TDataSet中,通过TDataSetProvider.constraints:=true
TClientDataSet可以把这些规则从DCom服务器中继承到表示层(用户界面)
目前的TADODataSet无法从数据库继承这些规则,所以我们要在CDom/Com+服务器中的TADODataset
组件中重新描述这些规则.
从以上讨论我们可以知道,使用Midas构架多层结构可以把这些规则写在服务器中,
客户端开发者不须关心诸如"请添入商品名称"等问题.
可是如果使用如HTML前端,就必须使用JavaScript等语言重新描述这些规则,由界面程序
作录入有效性的基本检查.
2.企业逻辑
我把开出一张单据,对单据进行批阅签发等动作理解为"企业逻辑"
企业逻辑不是对表的简单insert ,update and delete.
如对单据进行批阅签发是对表的update ,但我们必须在Com+对象中明确输出一个
"单据"."签发"的方法(接口)供客户调用.这个方法可能包含签发人和单据号两个参数
一个企业逻辑(往往是在协调对象中实现)可能包含多个实现对象的方法
3.查询是否在业务组件中实现:
灵活多变的查询是每个业务对象都要使用的,我们可能还要设计分包存取等烦琐的技术
细节使客户不至于一次查询大量记录陷入长久的等待中,如果在每个业务组件中都具体
实现一个QueryData方法会陷入烦琐而又不精致的工作中.
所以我建议使用公用的查询对象处理灵活的查询,这个对象允许带Selet SQL语句(不许
带Udate,delete语句),这样,一个典型的业务可以这样表达:
PublicQry.QueryData;
User.ChangePassWord(针对查询到的记录之一进行进一步业务处理)

4.如何获得ClientDataset的结构:
可以在一个公用的组件中获得某个结构,但它的缺点是难以对业务规则进行细化,
如果每个业务组件都有GetDataDefinds方法,客户界面的处理就会非常清晰
体会:
写一个无状态的多层结构应用确实不易.Borland和Microsoft并没有为我们
提供太多傻瓜化的东西,所谓"快速应用程序开发"还是神话
以上见解我自己也觉得不得要领,见笑

补充:
如果考虑太多的通用,就不可能在中间层封装业务逻辑,
一个大型应用,其Com+组件不会小于几百个.
我认为金蝶K3确实是一个国内比较优秀的产品,
观察一下其Com+接口,组件的数量和接口的规范性
都说明其组织设计者不简单
声明:金蝶与我毫无关系

感谢张鸿林

长篇大论不说了（以前也费过很多唇舌来阐述我的观点），这里简单说一两句吧。不管是
Borland的例程或是李维的例程，清一色地是把业务逻辑写在客户端里，而不是中间层的业务
逻辑组件里，这……真是误人子弟啊！这样一来带来了几乎和C/S一样的客户端维护工作量，
实在不应该是一个多层系统应该采用的方式。我做了几个中小系统，但都是按照业务性质的
不同而将业务逻辑代码封装在各个组件的对象方法中，程序做出来后看上去和李维的做法大
相径庭，开始时我也觉得很不安，但是后来我发现这种做法可以同时兼顾Windows程序客户
端和ASP客户端两种方式，能在最大程序上体现代码复用这一多层/分布式/组件结构的优点，
从而坚定了信心。

http://www.dekit.net/DWB/
我觉得企业逻辑可以写在中间层。
如货物的分货。补货等。
公司里有5种补货的策略。我用我写的控件来做。
把策略写在ASP或ASP.NET。然后由我写的多层控件来调用。
由于多种策略有时要微调。现在只需要修改中间层的ASP.NET。
就可以啦。由于ASP或ASP.NET可以直接修改。
所以修改策略非常方便啊。
所以我觉的ASP，ASP.NET，PHP，JSP。等都非常适合做我的控件的
中间层。

to Sachow，比较赞同你的观点，请问有之类的开发文档或demo程序吗？很想参考一下。
lanternsoft@163.com
谢谢。

正方vs反方: 三层结构干吗用的?
http://www.delphibbs.com/delphibbs/dispq.asp?lid=425874

多人接受答案了。