一个关于三层系统架构和实现方法的讨论(300分)

  • 主题发起人 主题发起人 davidc
  • 开始时间 开始时间
D

davidc

Unregistered / Unconfirmed
GUEST, unregistred user!
我公司现在正在进行一个大型MIS系统的开发,平台为Windows+SQL Server 7,开发工具
是Borland Delphi 5(注意:是Delphi),我们的技术总监定义了一种三层系统的架构,简
我公司现在正在进行一个大型MIS系统的开发,平台为Windows+SQL Server 7,开发工具
是Borland Delphi 5(注意:是Delphi),我们的技术总监定义了一种三层系统的架构。
备注:该技术总监多年以来一直从事UNIX平台下的应用开发,对C语言比较熟悉,对Delphi
没有接触过,自称对Informix比较熟悉,没有从事过SQL Server数据库系统的应用程序开
发。自称对三层系统有很深的了解(UNIX下),对COM/COM+知之甚少。对我们的系统所解决
的业务领域有初步了解。
下面,对我们现在的系统构架和实现方法中几个值得探讨的问题简单描述如下:
1、放弃了Delphi原有的MTS/MIDAS的数据封装和传输技术,只是利用了MTS的事务管理功能
通过数据库的表的字段定义不同的结构,自己进行交易控制、数据传输和出错控制。每一个
对单表(注意:是单表)的增、删、改、查作为一个MTS的事务,客户端传输过来的数据在中
间层被分解,然后组织SQL语句对数据库进行操作。
2、中间层服务程序对数据库的访问采用动态链接库封装,通过传递参数到动态链接库中,
然后由动态链接库进行数据库更新和访问。对数据库的更新进行显式的加锁,对于这样导
致的数据库死锁问题从业务面去分析解决(分析数据库中的近200张表,指定表的访问顺序)。
3、采用OLTP思想,实行短交易,也就是说,在进行多笔明细数据插入的时候,每插入一条
数据作为一个MTS事务,而多笔交易没有形成事务嵌套,这样的后果不用说也知道。对于插
入不成功的数据,在通过其他方法清除无用数据(引用总监原话)。至于清除无用数据失败
就不知道怎么解决了。中间还牵涉到数据的及时性问题。
4、我们创建了基于单表维护的自动生成工具,所有对后台数据库的单表维护中间层服务程
序都可以通过自动生成产生,但对于主从表的维护程序全部得通过程序员自己编写。
5、我们没有使用数据感应控件(数据感应控件有问题--引用),自己编写了Edit,ComboBox
和DBGrid控件,修改了Form单元,来实现数据感应控件所提供的功能。
以上的系统架构思想和程序实现思想是我们现在的做法,请大家指教。
 
很是有大家风范的一大笔!值得学习学习!
DCOM是效率较高的,当然选择MTS必定有你们的道理
》采用动态链接库封装
是不是。。。
对“单表维护的自动生成工具”有点不明白,有时间请详解,谢谢!
 
我的意思是说,我们对这个所谓的自动生成工具曾经寄予很高的期望,结果,这个工具只能
对数据库中的单个表的维护的中间层服程序进行自动生成,天哪!
 
>>我们没有使用数据感应控件(数据感应控件有问题--引用),自己编写了Edit,ComboBox
>>和DBGrid控件,修改了Form单元,来实现数据感应控件所提供的功能。
为什么不用现成的?
 
>数据感应控件有问题
有什么问题?
 
数据感应控件一点问题也没有,我提这个问题的目的是想请各位高手比较一下这种做法
与Delphi本身的MIDAS的优劣,请大家多提建议,不要客气。
 
我对你这个问题兴趣浓厚:)
等着瞧吧:)
 
这是C程序员的通病
 
这么大气的开发,还是头一次看到,
你们的那个项目不怕时间长吗?
这种系统构架和实现方法确实很好,
可如果用DELPHI的话,这就有点把简单的东东复杂化的感觉了,
但对于这个项目组的成员是一个好的学习机会,
我也想有这个机会...
 
1、如果放弃了Delphi原有的MTS/MIDAS的数据封装和传输技术,自己进行交易控制、数据
传输和出错控制,在效率和安全方面是否做得比MTS/MIDAS好?是否考虑到这样对软件的投
入是否会增加,风险是否会增大?。如果这些问题都考虑了,我觉得也不一定要MTS/MIDAS
结构,记得“速达软件”现在搞的ERP好象也把MTS/MIDAS给扔掉(本人曾经在“速达”骗
过几个月的工资)。
2、<中间层服务程序对数据库的访问采用动态链接库封装>,
是否用DCOM,如果不是的话,地层的通信还要操心,真“大型”。
<对数据库的更新进行显式的加锁,对于这样导
SQL Server 7可以行锁,死锁问题可以缓解。
3、为什么要“每插入一条数据作为一个MTS事务”,最少应该一笔交易(包括主从表)
有一个事务。
4、为什么“单表维护的自动生成工具”都做出来了,而“主从表的维护程序全部得通过
程序员自己编写”,也可以做一个“自动生成工具”吗。
5、至于数据感应控件的使用问题,问题不大,主要看你的编程习惯,我本人曾经在一
MRPII项目中一个数据感应控件也没用,全部用Edit、ComboBox、StringGrid完成。但我
不是说数据感应控件有问题,对,一点问题也没有,但不用数据感应控件也有它的好处,
如:程序比较容易搬迁、复制,如类似功能的一段程序(模块),我们通常做出一个后,
就用复制、复制再复制的方法把它变成多个,完后要改动的地方主要是代码,就不用在
Editor、Object Inspector和界面上来回的切换,改这属性,改那属性,而且不用在界
面上改主从表的关系、各个数据感应控件所关联的Table,Field等,条理清晰一点。只要
代码的通用性方面多下点功夫,对于MIS和MRPII之类的东西提高开发效率很有效(MIS和
MRPII之类的东西类似功能的程序(模块)太多了)。

 
还好没有叫你用java写中件间
mts对事务的管理还是比较好的,应该说比midas稳定
 
自高自大,是部分国人的弊病阿!
 
提问者:
如果你还要继续讨论请定期提前你的帖子,如果不想继续讨论请结束帖子。
请认真阅读大富翁论坛规则说明
http://www.delphibbs.com/delphibbs/rules.htm
 
你的技术总监也上大富翁???
 
我觉得大项目还是不要用DELPHI的那些数据敏感控件的好,用它们是贪小便宜吃大亏
自己做的东西要稳定可靠可控得多
 
davidc:
你好
可否留下mail.
我的 mail: liuyj@zhonghuan.com.cn
 
My Mail: davidc@cn99.com
 
什么都重写

什么不重写呢?

c 程序员的弊病
 
后退
顶部