从实践中学习

   上午跑到技术部拷费收系统，跟小唐，小唐和小梁聊了一阵，主要是涉及到我们开发生产系统这个过程的问题，应该如何进行企业级开发，最后小唐（唐学武）给我演示了一下他们用的基于流程管理的OA系统。

    他们觉得我们作系统有以下问题：

   1、数据库设计的太随意，把收集上来的单据直接变成数据库表，然后界面是错误的做法。唐学武说做的简直就是打单系统（也就是报表系统）。

   2、代码写的太滥，冗余重复的代码太多，应该使用OO。小梁一直在维护该系统，感触颇深，具体而言包括：

     1）函数太长，用小梁的话说就是大家似乎就是为了能把程序作出来面向实现编出来的程序，一气下来，也不说把代码分解一下。我最近往地磅系统里面加入视频监控功能，结果遇到一个1111行的函数，真是崩溃。小梁说，我看到一个代码

     2）到处重复。好多重复的代码，if else段中的代码超多重复的代码。

     3）代码太随意。很多代码写的很有问题，好像是随便写的，权限控制的代码时间复杂度是n的6次方，访问了上千次数据库，而且还有大量重复的数据库读取操作，速度能不慢吗？代码随意也就罢了，也不重构，代码越来越恶心。

   3、应该从业务出发，业务逻辑和数据库应该是分开的，数据库相对稳定，而业务逻辑可以变化。我的设想是，先从业务逻辑出发，看哪些需要持久化，在设计出数据库。他们认为搜集些单据，然后设计出数据库，容纳后设计界面的做法是错误的，应该从业务出发。

 

   小梁认为生产系统存在大量的分支情况，就应该使用面向对象技术，我想他指的是利用多态。而唐学武则认为大处用面向对象，小处用面向过程，而小的地方可能只限于一个方法内，可以使用过程式的代码。

 

   唐学武认为，调研时不应该仅仅按照部门来设计系统，而应该从全局角度出发（如果你够敏感，应该想到工作流中，我们是先有流程，然后来配置角色，和这个想法是一致的）。

   小梁认为，业务系统应该和报表程序并行开发，数据库中存在的内容要够未来的统计系统使用。我得到的启示是，统计数据库和业务数据库设计的出发点是不同的。我在做OO设计时，考虑的是什么样的数据需要持久化，因为有些数据必须在新的会话中可以获得，在宕机重起之后还可以读取到内存中。而统计数据库的目的是需要基于这些内容进行统计分析。我想更多人将这两种诉求混为一谈了，什么都持久化到数据库中从业务角度来看是没必要的，而对于统计而言，很多数据确实是需要持久化到数据库的。对于数据库的认识我终于找到了我和黄老师，刘老师的分歧，我受到很大的老外那些J2EE，体系结构方面的书的影响，觉得数据库不过是个持久化机制，你也可以持久化到文件系统，XML中之类的，所以我过去很少对数据库特性进行研究。而黄老师那时候一句：在MIS中最大的软件其实是RDBMS。所以IBM的信息管理产品就是DB2。

 

   后来唐学武给我看了他们用的基于流程的OA，觉得这就是传说中的随便画画就能搭建各种系统的东东，就是那类能改变人生观的平台。他这个还有缺陷，比如并发访问控制的不好（事务与并发，世界性难题，我们目前遇到的很大的问题就是这方面的设计，我一直也觉得这类平台的问题就在这块儿，他们能很好的解决简单问题，但是复杂问题解决得不好或解决不了）。不过他的这个体系结构还是很不错的，先设计一个单据，如果这个单据要经过四个步骤（就是jBPM中的节点），那么就在这个单据上设定每个内容应该由谁来填写，还可以设置这部分内容加载时会触发什么函数（可以用VB语言来写，我想是不是类似于Justup那个可以利用Delphi语言来写？），也就是jBPM中进入这个节点之前会调用Action做什么事情。用户可以自定义函数，它提供了现成的访问数据库的函数，代码很简单，和我过去编的访问数据库的通用函数一样。这样就可以自己定义函数访问数据库，存取数据，进行计算，展开业务逻辑了。说真的，这个完全可以搭建起这样的数据驱动的系统，而且它还可以扩展，我想刘老师所谓平台，大抵就是这个了！这个平台我们用jBPM完全可以实现，而且会实现的更好。

 

    回去看集团信息中心编的费收系统，我竟然在黄老师给我的文档中找到了源程序（他还让我向小唐他们要源代码呢），阅读了一下，真的很惊叹，他们的体系结构设计的真的很不错，而且文档很专业，各种业务需求非常明确，还有PPT版，我想他们一定对每个需求都反复的审查过，专业啊，就是不一样。

   首先他们做了分层，数据库逻辑写在了存储过程，函数，触发器中，然后为窗体建了一个DataModel，里面都是访问数据库的控件，这样就分离出了数据库访问逻辑。

   他们建立几个BaseForm，一个最基本的Form中定义了所有窗体都会用到的虚方法，比如Save之类的，我感觉他们使用了Template Method模式，在子类中给出具体的数据库访问控件和SQL语句，比较经典的是下面这段：

Delphi代码

procedure TBaseForm.Delete;

          begin

              if not QueryMsg('删除当前单据吗？') then Exit;

              with TOraQuery(dsMaster.DataSet) do

                 begin

                   try

                       StartFeeTrans;//事务开始

                       Delete;

                       ApplyUpdates;

                       FeeCommit;//事务提交

                    except

                       FeeRollback;//事务回滚

                    end;

                  end;

           end;

       

     Save方法与此类似，然后在其他窗体里就可以继承这个窗体的方法，把dsMaster和具体的Query联系起来，然后就可以处理了，而且不用重复的写这些事务代码，很不错的写法。

     他们对于数据加锁和解锁都有考虑到，可以说很专业。

     不过关于业务层处理事务的共识，好像在这里并没有体现，这是我最近在研究的一个重点。

     然后在Form中只需要写些读取数据的代码就可以了，他们充分的利用了ODAC的现成方法。他们在BaseForm中还使用了TActionList对象，很好的解决了控件状态的问题，不过我觉得Delphi在设计Action时不只是考虑这点，我在想它是否和Swing中的监听器是一个概念呢？如果是的话，那么我们可以编写出耦合度更小的Delphi。

   

     可以说，看了费收系统的代码，让我对于Delphi企业级开发的理解又迈进了一大步，有空的时候我会好好整理一下思路，仔细研究一下他们的代码，真的很不错，而且经过我们的改进，一定会更好，因为在J2EE的研究中，我已经获得了很多经验。

 

     从实践中学习，才会学的更深！我想昨天跟文文聊过，她应该会很赞同我的说法~~

  

 

  

分享到：

RESTful Web Services 前言(翻译) | 爱与愁

• 2007-12-06 22:34
• 浏览 1098
• 评论(0)
• 查看更多