三层中的业务封装
好久没来这里，我来尝试着为初学者做一个入门讲座。
业务：客户的需求描述稍作整理，就可以认为是业务
业务逻辑：业务的计算机具体实现，对于数据库应用来说，往往可以具体为一个SQL语句
你现在正跟客户进行关于工资模块需求的交谈：
客户说，我想要查某个部门的工资表，有时需要查某个人的工资表，这个工资表是按月查询的
你现在可以根据这个需求建立这样的工资服务模型（基于Com+）：
mtsSalary.dll
function GetMonthSalaryByDep(DepartmnetId:WideString;Month:int;
out Data:OleVariant)
function GetMonthSalaryByEmp(EmpId:WideString;Month:int
out Data:OleVariant)
以上两个函数事实上是Mts的接口
第一个函数的实现核心：
select * from Salary where Dep_id=:DepartmnetId and Month=:Month
第二个函数：
select * from Salary where Emp_id=:EmpId and Month=:Month
封装业务逻辑的基本要求：
不要随便在客户端传递sql语句，典型地，客户调用某个服务的某个方法（接口），传递调用参数，客户端不知道数据库的存在
以下是客户端的调用原型：
function GetMonthSalaryByDep(DepartmnetId:WideString;Month:int)
var oSalary: ISalary
Data:OleVariant;
begin
oSalary:=CoSalary.CreateRemote(ServerName) as ISalary;
oSalary.GetMonthSalaryByDep(DepartmnetId,Month,Data);
//do something show the data;
oSalary:=nil;
end;
以上只是伪代码，这种设计方法，代码实现与需求描述相当一致
谢谢你的讲解。
还是有些不明白，如果像这样，都封装为接口，我觉得有二个问题：
1、双方要协定那个OleVariant的格式
2、服务端要组成一个大包后发出，客户端要解包后才能显示处理，这效率不是很低？
程序员的成长历程
接到了一个开发任务:
为航天飞机设计一个驾驶方法
入门者:
TForm1.Button1Click(Sender:TObject);
begin
加燃料
开门
进去
穿航天服(刚才忘了,后来补进来的)
启动
呵呵,飞起来了
(代码超过1000行)
end;
学了一点OO概念:
T航天飞机
private
加燃料
开门
进去
穿航天服
public
驾驶
end;
完美的OO主义者:
T飞行器
proitate
...
public
驾驶 Virtural
end;
T航天飞机=class(T飞行器)
proitate
...
public
驾驶 Virtural
end;
拆分狂:
把"T航天飞机"封装为Com+,
在这基础上作了ASP封装,WEBService封装,
或者,J2EE,Corba, .net ...
交待他的团队:A写WEB飞行界面,B写ActiveX飞行界面,C写...
反扑归真:
航天飞机.pas
interface
function 驾驶:boolean;
implimentation
procedure 加燃料 ;forward;
procedure 开门 ;forward;
procedure 进去 ;forward;
procedure 穿航天服 ;forward;
end;
然后交待他的团队完成其他任务
回 ：
还是有些不明白，如果像这样，都封装为接口，我觉得有二个问题：
1、双方要协定那个OleVariant的格式
在DELPHI中，一般使用MIDAS技术，其格式就是TClientDataSet.data
用Xml封装也是一种常用方法
2、服务端要组成一个大包后发出，客户端要解包后才能显示处理，这效率不是很低？
一般的入门者，在客户端用DComConnection ,效率是一样的
对于多层结构编程，每次不要访问（传输）大量数据是基本要求
以Com+ & WEBService技术来举例：
一个数据包经过这样的传输过程：
database->com+->WebService->客户
传输过程中还涉及到编码、解码
性能确实有问题，所以对每个细节都要精心设计
首先肯定得说：多层系统绝对是要比两层系统要效率低，道理说白了很简单，本来数据从生产商直接到最终顾客，现在数据被多个中间商倒手，不慢才怪。
下面我来谈谈，多层系统中提升效率的几个关键点：
1，层次尽量简单，数据在层次之间进行传递，效率非常低下，因为数据经过不断的封包、解包过程，而数据封包解包过程是影响效率最直接的原因，所以一定不要让数据在中间层之间进行传递。
2，接口事务明晰，采用不同事务模式的接口执行效率是不同的，所以不需要事务的地方一定使用不支持事务的接口，尽量减少不必要的性能耗费，而需要事务的接口也要明确判断所需的事务类型。
3，取数尽量精简，大量数据的存取对于多层系统是致命的危害，所以取数应选择最少的不可缺少的列，尽量采用条件取数，该取数时再取数，不要动不动就把数据取一遍。
4，提交事务短暂，事务的发起和结束在尽量短的时间内完成，不要发起事务之后再做很多编辑计算工然后才提交，尤其对于一些公用的表，一定不要长时间占用，否则一个操作执行，其它操作都无法进行，你会死得很惨得。
5，数据库设计合理，字段使用不要洋洋洒洒，一定要合理设置类型和长度，效率来源于点点滴滴，数字类型比字符类型的效率要高很多，多使用视图和存储过程，存储过程的使用对于执行效率和程序的可维护性都大有裨益，而触发器最好少用，对于效率和危害性都有很大影响。
