读书人

用Delphi做大型项目怎么构架

发布时间: 2012-03-21 13:33:15 作者: rapoo

用Delphi做大型项目如何构架?
有个项目很大,请问怎么打框架,如何构思?

[解决办法]
1.如果对业务要求足够复杂,且对实时性要求不是很高的情况下,做一个O/R Mapping框架还是可以尝到甜头的:)。O/R Mapping不一定要像Hibernate一样复杂,仅需要实现XMLToObject/ObjectToXML(序列化与反序列化)与ObjectToSQL/SQLToObject即可,同时对于整个框架中对于实时性要求比较高的小业务点也可采用直接与数据库进行交互的方法,不过这部分越少越好,不方便数据库的升级!顺便说一下,这段时间没仔细看关于存储过程是否过时的贴子,不过个人认为对于数据一些大规模推拉操作、多业务数据库数据点采集、以及数据的简单批量的业务逻辑计算、报表数据生成等放在存储过程中还是不错的。
2.业务逻辑层写成插件形式,不管是使用COM+,还是转为WEBSERVICE,均保持一种SERVICE BROKER调用业务插件的形式。另,数据访问层用Delphi写服务器端可能会稍稍费点劲。
3.把Delphi做成富客户端,也做成一种插件形式!每次点击业务结点时,保证版本的最新!对于传输协议以及传输介质,可以根据实际情况来做处理
[解决办法]

架构是一个非常有技术难度的东西(小系统除外)。就软件架构而言,它
甚至可能是一个软件公司的支柱(例如:国内建筑NO1的广联达,做CAD的美什么公司名忘了)。

好的架构师需要对OO的思想非常理解(OOP,OOB,OOA)。
对设计模式有深刻的认识(Abstract Factory适合什么,Flyweight适合什么)
同时还要对业务有深刻认识,
才能设计出一个较好的架构(架构永远没有完美的。。)

说下来,工作6年以上才能够谈到架构,(对我等小民,牛人除外)
//=======================================================================
大项目如何构思?(个人一点小意见)

首先考虑成本。需求。
如何用最低的成本完成客户的需求?

先考虑系统硬件架构。
例如:能用2台服务器的,别用1台。硬件成本一般不计算在开发成本的,可以帮你省钱啊。除非客户要求,
不过这样的客户很少。
硬件好了,帮你降低开发难度,节约成本。

客户对数据安全要求高(特指存储安全)那就增加热备的磁盘阵列,换高端数据库,如果要求速度快,
那么加带宽,加分配器,加服务器,或者集群。(只要你有足够的理由,客户不会反对的,也是为他
的系统好)

在考虑软件架构:
一般的规则是:尽量用成熟的东西,开源的东西。
(成本低,而且经过验证,Delphi的项目不是那种高精尖项目,如游戏服务端,企业应用居多)
如果重新设计,那么首先看需求,将需求提纯。用类来表示。
在设计中使用不同的设计模式 ,解决不同的问题。
(这样,无论是升级或者更改需求,都不会让你大动干戈,我们的一个项目,采用这个方式,开发都结束了,客户要求更新一些数据库设计,貌似客户还懂点技术,知道麻烦,挺不好意思的,实际上仅仅40多行代码,修改完毕。
还有一个基于WebService的项目,无论怎么更新数据库和XML,Delphi客户端基本不用修改,自适应。。。)

个人一点小意见,题目太大,简单说说,楼主看看有用没,大侠看了也请指点下。



[解决办法]

探讨
1.如果对业务要求足够复杂,且对实时性要求不是很高的情况下,做一个O/R Mapping框架还是可以尝到甜头的:)。O/R Mapping不一定要像Hibernate一样复杂,仅需要实现XMLToObject/ObjectToXML(序列化与反序列化)与ObjectToSQL/SQLToObject即可,同时对于整个框架中对于实时性要求比较高的小业务点也可采用直接与数据库进行交互的方法,不过这部分越少越好,不方便数据库的升级!顺便说一下,这段时间没仔细看关于存储过程是否过时的贴子,不过个人认为对于数据一些大规模推拉操作、多业务数据库数据点采集、以及数据的简单批量的业务逻辑计算、报表数据生成等放在存储过程中还是不错的。
2.业务逻辑层写成插件形式,不管是使用COM+,还是转为WEBSERVICE,均保持一种SERVICE BROKER调用业务插件的形式。另,数据访问层用Delphi写服务器端可能会稍稍费点劲。
3.把Delphi做成富客户端,也做成一种插件形式!每次点击业务结点时,保证版本的最新!对于传输协议以及传输介质,可以根据实际情况来做处理

读书人网 >.NET

热点推荐