三层程序的中间层到底该如何定义企业逻辑？（高分奖励有建设性言论者）(200分)

V

VeryCoolBoy

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2001-12-19

• #1

三层程序已有极为普遍的应用啦，但时至今日，我对于中间层到底该做些什么仍是一片迷茫，
在这里想假定一份案例，大家发表自己的看法，看看中间层到底该如何定义接口，怎样做最合
理，请大家不吝赐教，特别声明：本案只是作为讨论举例，绝无任何商业目的，并且也绝无借
刀之意。
假设有某家跨区域的公司要做一人事档案系统，要求：
1。基本数据录入
2。员工工作调动（职级调整、工作岗位调动）
3。劳动用工合同
4。劳保用品发放
5。。。。。大家自己想吧。
那么基于上述要求，中间层的企业逻辑如何定义？需要如何安排接口？
如果大家觉得这个讨论有一定的价值，不妨都“出钱出力”，有分的为那些提出可行方法的
大侠加分（我个人愿出500分以上），不够分的帮忙把问题提前啊！！

 

B

bessxq

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2001-12-19

• #2

来听课！！

 

T

t1122

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2001-12-19

• #3

look:
http://www.delphibbs.com/delphibbs/dispq.asp?lid=796709
对你的系统分析有好处。

 

T

t1122

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2001-12-19

• #4

我到做过类似的一个，省级的，建议用treeview来体现数据库的层次关系。
有时总局中的人员和市局单位在一个平面上，但是一个是人员，一个是单位，
就想文件和子目录，树壮视图最能体现这种关系。
还应该有以下几个：
5考评体系
6工资体系
7贡献系数体系
8具体贡献度
9培训体系
10激励体系
11…………

 

T

t1122

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2001-12-19

• #5

逻辑层定义应以信息变更为主线，就是看各种人事信息变化，比如年龄、职务变化、贡献度
工龄、部门变化、合同变化、学历变化、培训变化、技能变化、假期变化等等来定义。

 

V

VeryCoolBoy

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2001-12-21

• #6

各位大侠，其实我主要是想讨论我们该把哪一些东西放到中间层，哪一些东西放到客户端，
甚至于哪一些东西放到存储过程或触发器中，也就是说，如何处理这些层次之间的关系才能
真正的发挥出三层结构的优势，既然是三层程序，总不至于在中间层中只放置数据块而不写
接口吧，那样的三层又有什么意义呢？但接口函数又应细化到一个怎样的程度呢才合理呢？

 

R

Ricezj

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2001-12-21

• #7

我也认为这个问题很有价值，我现在也很想知道中间层怎么设计表较好。
我看了这里的千份大讨论的一篇文章，就是关于三层的系统怎么设计，有利于Client的简洁，
中间层的逻辑清楚，以及维护起来改动中间层不用或很小的改动Client端。
我认为中间层应该分有逻辑模块，数据交互模块，功能处理模块等等，但是我很想学习各位大虾
的设计思想，以及模块设计好后，怎么能够使Client端有很少的SQL语句？数据更新怎么做理想？
希望得到大虾的意见。能够有例子最好！（是不是有些贪心）

 

T

trackboy

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2001-12-21

• #8

gz

 

S

softdog

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2001-12-21

• #9

现在正在学习这方面的东西。
我认为数据库上应尽量少用触发器、外键等东西，一些复杂的操作可以使用存储过程。
在中间层上也应该区分两个层次，第一个层次是一些小的对象，比如产生一个单据编号、定义
数据连接等；第二个层次是封装一些真正面对客户的对象，比如一个单据，然后在这个对象中
封装一些操作，比如：新增、删除、过滤等等。在客户端尽量调用这些封装比较完整的对象。
在客户层上应该完全不使用数据连接控件，所有数据集都应该从服务器对象中取得，客户层只
负责一些和用户交互的东西。
这些只是我个人的想法，还望大家指教。
我愿意再出500分，欢迎大家讨论这个话题！

 

F

flysand

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2001-12-21

• #10

本人认为:
一般来说,能用存贮过程的尽量用,
一些不能用存贮过程不能很好实现的,但又不需要在客户端交互处理的逻辑运算
或特殊的处理就放在中间层.
用中间层的还有的好处就是连接pooling;
还有一个,一个应用服务器只需要购买一个用户版的数据库提供结无数用户连接使用

 

B

bluepeach

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2001-12-21

• #11

我不建议使用存储过程，原因1是对数据库的依赖太大。原因2是如果用中间件如COM组件来替代
存储过程同样可以有近似的性能，并可以灵活的分布，高可用。

 

G

guilinlzy

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2001-12-24

• #12

将数据处理及通信功能封装在一个共享的中间层里。不同的客户端程序都能访问这个中
间层，这样就避免了为每个客户程序复制数据处理部分而产生的冗余。
在多层模式下，几个客户有可能同时与一个应用服务器通讯，应用服务器实际上充当了
网关的作用。

 

D

drummer

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2001-12-25

• #13

l

 

C

chinaplate

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2001-12-25

• #14

听课

 

雨

雨人

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2001-12-25

• #15

建议用uml分析设计
定义企业物件
员工对象（方法：雇佣，解雇，职级调整、工作岗位调动....)
合同对象(方法：签定，续约。。）
。。。。

 

F

freeswordman

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2001-12-30

• #16

所有对数据操作的功能均放淤服务器，在中间层建立连接池，用COM组件提供借口给客户端，系统可以无限扩展

 

C

ChinaYA

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2001-12-30

• #17

正在学习+思考中 ……
关注.

 

V

vickymade

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2002-01-02

• #18

Middle + COM+

 

T

taozhiyu

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2002-01-02

• #19

GZ

 

T

tuti

Unregistered / Unconfirmed

GUEST, unregistred user!

• 2002-01-18

• #20

这类问题的解决，只能靠对需求的深入分析和不断抽象。另外一个是靠经验。
泛泛而谈没什么意义。一般来说分析透彻了，问题的答案也就基本浮现了。