关于三层架构的讨论(com+)(100分)

  • 主题发起人 主题发起人 looyo
  • 开始时间 开始时间
L

looyo

Unregistered / Unconfirmed
GUEST, unregistred user!
我准备运用的是com+来完成三层架构,但是我不知道交互界面是不是应该封装在com+中
还是将交互的界面以DLLFORM的形式存在,放在本地。
com+是不是最好用于封装一些计算量大的业务逻辑。简单的计算和业务是不是应该让客户端
直接和数据库联系呢。那样的系统就是CS和CSS相结合了。
 
一、交互界面使用IE浏览的方式。不需要封装。
二、如使用B/S模式,把业务逻辑、计算写到中间件、数据库中。
 
Cut.fei:不是任何系统都适合用bs结构的,如果是局域网应用,需要操作员快速的输入
数据、人机交互频繁,且交互数据量大的情况下就不适合用bs了。
我曾经做过用bs结构的his系统,结果比较失败。
门诊批价结算等功能需要用户快速的输入数据,并且输入数据的时候需要lookup数据库中
的数据。browse在方便用户输入方面的功能就显得太单薄了。在输入界面比较
复杂的情况下,cs结构的客户端程序可以让用户只使用键盘完成所有操作,还可以定义快捷
键等,browse不能做到
 
现在有一种说法就是回归CS方式,在大数据量处理和快速数据录入情况下采用CS方式
更好一些,用于减轻应用服务器的数据处理量,发挥客户端的资源优势。
当然CS也是做成三层的。
不知大家如何看待?
 
其实现在很少是C/S,一般都是多层结构.区别在于前台是用专门的程序还是浏览器.
交互式操作要求比较高的,建议用专门的程序,简单查询的用浏览器比较方便.同时开发速
度也是要考虑的一个因素.毕竟开发浏览器的程序比较慢,而且运行速度也不是很快.
 
又对C/S和B/S的应用范围有了更深的认识!
关注。。。
 
关键是必须进行逻辑分层,物理分层是次要的。
 
1.我认为将Form以Dll封装到本地比较好.一方面可以减轻服务器端的负荷,另一方面这样也
比较灵活,如一些客户界面的特殊定制等等.
2.如果我作三层的话,一些简单的对数据库操作会作在Client端.对编码来说比写在server端
工作量要小,不过这违背了三层的宗旨....
对于一个非常大的系统,这样作是不可取的.试想如果有上千个终端的话......所以呢,这就有
了一个系统分析的问题.如果终端很少(<10)的话,作成三层还不如C/S结构.
 
关于三层结构的结构确实头大:
我现在的结构是:
客户端用DLL封装FORM,然后在调用中间层,我们的中间层是用
协调对象调用MTS远程摸板的形式的,然后在远程摸板中放入数据对象
这样的结构已经做了一个系统:完成了事务处理的功能
但目前的问题如下,也希望各位富翁或富婆关照:
目前在客户端通过接口的CreateRemote(MachineName)而MachineName只是一个特定的
远程机器名做应用服务器,无法进行动态切换做到负载平衡的,另外了我们的连接池
也没做不知道COM+/MTS的连接池该如何做,如果哪位有高见
可以发到tm.wang@tech-aggression.com
当然有高分相送,楼上的分数可不必给我了。



 
想问一下,中间层都要做些什么,
我的每个业务模块在中间层都要有一个对应的模块或者东西来处理吗
MTS好像只能写到DLL中去,能不能也写成应用程序呢?
 
COM+封装所有的 业务计算 和 规则
 
1)如你的系统用户在200端 用c/s ;
2)com+ + procedure + trigger 实现企业业务逻辑 ;
3)客户端 dll 或 用asp 等,完成简单的合法性验证 ;

欢迎讨论!!!!!!!!!
 
什么是业务计算和规格啊?
判断一个字段值是否合法算不算啊?
如果不算那放在前台吧
以前是大于零合法,现在是大于等于零合法,前端要不要改啊?
改? 1000个终端!
如果算,那该怎么放啊?
三层我是菜菜鸟!
不过对于我目前所接触到的三层代码,实在是不太明白。
中间层有什么? 不就是个数据模块嘛,主从就一关联,然后放个提供者组件,
什么业务? 什么逻辑? 在哪里呀?
 
>以前是大于零合法,现在是大于等于零合法,前端要不要改啊?
>改? 1000个终端!
我们把客户端程序放在文件服务器上,终端只有快捷方式。
权宜之际,不过确实可以减少维护的工作量。
关于中间层到底做些啥,我想至少可以:
1、数据库连接,这不用问的。
2、登陆验证。
3、权限和流程机制
对于数据录入、修改、查询,好像没什么区别。
而交互式界面,那更应该是客户端需要解决的问题。
 
楼上说的不错。
不过
流程机制太抽象了,说点实际运中的例子举证一下也好啊
 
>流程机制太抽象了
流程仍然在探索之中。以下仅仅是我的设想:
1、流程的建立
以合同为例,当需要和客户签订合同是,需要根据合同的相关信息来决定使用哪些流程。
比如金额的大小,客户的信用等级等。
现在使用的是函数:
function getCanUsedProcess(hetongId:Integer):TStrings;
可以把这个函数给放到中间层去。
2、流程的流动
包括某个合同的流转、驳回、终止、拉回、强制流转等等
都可以写成对应的函数,放在中间层,由客户端使用。
不过我在想这样中间层必然有无数的函数。要理解这些函数和这些函数之间的关系
肯定要化大量时间,特别对于不是编写这些代码的人。
也许把流程处理封装成对象在可理解性要好些,可是如果写好了这个类,我还不知道
如何移动到中间层去。
 
三层我是菜菜鸟!
 
一个C/S应用中,把要用到的重要业务逻辑功能函数封装到DLL中,是不是就算三层了?
敝人比较菜,请大家不吝赐教!
 
三层结构,我接触很少,有些问题请多多指教。
1.我觉得如果使用三层结构的话,速度很有可能降下来。我是用视图显示数据,

存储过程修改数据。
2.我把一些业务处理写入了存储过程,是不是需要把存储过程搬到应用服务器吗?

如果不是,那应用服务器干什么用啊...
3.三层结构中如果存在了Internet和局哉网,DCom配置,网关问题是不是很烦啊.假设
局哉网通过ADSL之类上网呢?!
4.以上几种情况的项目有没有必有改成三层结构,或BS结构。希望有好的建议。500分支持.
感谢楼主!,有讨论的机会!定会送100分与楼主.
 

Similar threads

S
回复
0
查看
3K
SUNSTONE的Delphi笔记
S
S
回复
0
查看
2K
SUNSTONE的Delphi笔记
S
D
回复
0
查看
911
DelphiTeacher的专栏
D
D
回复
0
查看
868
DelphiTeacher的专栏
D
后退
顶部