Delphi MIS开发架构心得 - Delphi

广东,东莞,昨夜闷热.睡不着.想想琢磨软件开发也很久了.都是业余,没做成什么.可是看了不少东西.看了一些商品化软件的结构.为免新入门的朋友多走弯路,现本人一些体会说出来大家共同学习.许久没用delphil了,里面有些说法可能不准确

一关于开发工具.数据库比较流行的是Delphi + Sql server.Delphi的好处我就不多说了.大家可以在网上找到很多.至于选择Sql server的原因,一是对中小型企业来说,Sql server的性能也还可以,价格相对于oracle 来说要便宜很多.再就是Microsoft的东西在易用性方面的确下了不少功夫.帮助资料齐全,本地化的语言也做得好.再加上目前国内的版权意识不是很高.所以选择Sql server的人很多.其实开源的firebirdsql , postgresql等等也还是很不错的,又不用花钱,但在国内用的人很少.

二关于数据库连接层.用Borland 的BDE还是MS的ADO,到底哪个好.(新的dbexpress俺没用过,不敢发言).其实BDE和Ado都很优秀.BDE因为不是windows的东西,要另外安装,比较麻烦些.Ado则是高版本windows内置的.目前来看,用ADO的人数远远大于用BDE的.但BDE有一个好处,它的更新可控制性要比ADO强.它有一个UpdateSql组件,可以自定义更新的三种sql语句.这个优点已经被ADO.Net吸收了.

三关于三层还是两层的问题.看了一下国内和台湾的几家较有名气的软件公司.三层是大势所趋.但目前做两层的还是多数.国内神xxx的Erp软件,台湾统x的软件用的是三层,同样用的是delphi的开发工具.东莞有家小软件公司做的进销存也是三层.都用的borland的midas技术.
国内的速x Erp是个假三层的,怎么说呢.它有个后台”应用程序服务器”在运行,但只起到客户端的连接监控作用,商业逻辑仍然是放在数据库后台的.所以说是假三层.

四关于面向对象与关系数据库的矛盾问题.网上讨论很多.牵涉到三层的设计问题.牵涉到对象感知组件的问题.国外也有很多讨论.解决的方式大致有两种,一种是不用或者少用数据感知控件,自己写代码控制数据的变化控制与输入输出.这样可以封装实体类.以实体类或者实体类集合来工作,另外创建功能类,在功能类中写方法操纵实体类.不过这样一来工作量很大的.需要有 object/relational自动映射工具帮助实现.第二种是用数据感知控件.并且以dataset为中心.需要自己创建的实体类很少.商业逻辑还是要写sql语句,不管是放在什么地方.就是存储过程也不过是预编译的sql语句集合.这种方式比较大众化,对部分程序员的要求可以放低些(不要误会说这种方式的水平低).而且可以配合midas技术使用.国内神州数码的erp就是用这样做的.

五. 关于midas技术中的商业逻辑怎样安排的问题.台湾李维的书也将midas,也讲商业逻辑.但他好像没有怎样用midas实现商业逻辑(也许李维讲了是本人没有看到.).其实这个商业逻辑很简单,就在那个DataSetProvider的beforeapplyupdates 和afterapplyupdates中自己写好了.在这里要检查哪些值改变了,改变量是多少,针对这些改变量,我还要改变数据库中其他那些表的哪些记录的哪些字段值.举个例子.以开一张销售出货单来看.该张销售单卖了A产品100个,B产品50个,那么要在库存现存量中减去A产品100个,B产品50个,在财务的应收帐里加上这个客户本张单的欠款.具体要看你的数据库设计和数据流程.通常的erp软件里面商业逻辑很复杂,往往要改另外5,6个表以上,包括增,删,改都有可能.通常在数据库中写好store produce ,然后在中间层调用.这种情况基本上不用写触发器(trigger).对应触发功能是由应用服务器完成的.但如果没有用midas,是两层结构.往往免不了写trigger.是否另外写store product看情况需要.一般不推荐在客户端写商业逻辑,一方面编程难度加大,这种方式对用户的数据操作必须及时跟踪.另外修改了商业逻辑必须重新编译代码.不像在数据库端改了触发器即时生效,而且通常客户端较多,而数据库服务器只有一个,不存在版本更新的分发问题.