MIS系统架构的一些局部位置的设计思路..doc

这里讲的是对MIS系统架构的一些局部位置的设计思路，也是我个人的想法，不敢以偏概全，不过包含了很多要素：权限、验证、流程、行为、结构、内容，还有表示层如何与业务层分离。 写在前面 这是对以前项目的总结，作为一个在别人架构的系统上写程序的开发人员，对系统架构提出新的想法我想这没什么可争议的。 我经历了两个业务需求相似的项目，第一个项目我看不到架构的影子，看到不少用工具根据数据库生成的看起来很优秀的代码，花了几个月修改bug但最后项目还是黄了，这次的失败给每个人都上了堂课。但我到公司的时候负责架构的人和多个开发人员已经不在公司了，那时写代码的工作已经接近尾声，主要就是测试、改bug和报表，我是和剩下的人一起共事的。我到公司后就做报表，用DevExpress控件做报表，以致我对DevExpress的XtraReport报表很熟悉，之后在第二个项目中负责报表并写了关于XtraReportbug了，改bug很容易，在我的印象中发给我的bug我都能改好并不会产生其他的bug，而且还对原有不合理的程序进行了优化，但遗憾的是在之后的几次演示中系统都没能完全的毫无错误的正确的走完。其中客户很挑剔，关于这个我是理解的，如果我们去买房子当然希望房子好的出乎我们的想像。项目无功收场，很多同事离去了，曾经大家起吃住欢笑的日子不在有了，特别是我们的经理，他离开让我很意外，当初就是他面试我进公司的，面试时只是让我做一个类似新闻发布系统，我甚至没有做出来，他看了下代码和我平时瞎捣鼓的东西，到会议室问我期望的待遇，约好时间我就来上班了。他走时我送了本书给他，现在元旦时他还会给大家发条祝福的短信。 这次和剩下的几个人和另一组人进行了第二个项目，我从这边转到那边时架构已经做好了，当时我当心架构会跟前一个项目一样，到了之后看到比前一个大大的改进了。这个项目架构的很好，特别是界面层，界面进行了统一，或者说是标准化了下，一排按钮整齐紧挨着排列，每个按钮放在一个lebel上，设置这个lebel不可见后面的按钮会紧挨着跟上来，这点做的太棒了，它能给界面层设计带来很多启发，这点是我没想到的。这个架构将很多操作定义好，有时候像是定义死，不同的操作它会执行不同的代码并传不同的参数给一个虚方法，派生的窗体重写这写虚访法完成对业务层的访问（业务层往往是调用存储过程）。负责某个模块的开发人员要做的工作就是：写好各操作的存储过程；定义业务层对象；选择正确的窗体基类（主要有带树形的列表窗体、列表窗体和明细窗体）派生一个新的窗体，在这个窗体中使用业务层对象和一些公共对象做权限设置等初始化操作以及验证，复写虚访法，很多的地方都是用虚访法的，如验证，基类的事件中去调用这些虚访法，还有访问业务层对数据的操作也是在虚访法中去访问，基类会去调用这个虚访法。开发人员要写很多的if语句，并且大量的代码都在界面层去做，业务层显得及其单薄，当然架构人员当初肯定不是这样想的，实际工作中开发人员在没有指导和参考实例的情况下违背了架构人员的初衷。这个项目最后是成功的。 学会总结，争取每次架构比前一个架构更进一步。 简单而繁琐的工作——开发人员的痛 一个好的架构可以让开发人员有个赏心悦目的体验，他可以简单愉快的面对繁杂的业务问题，将精力放在困难但能给人带来挑战性和成就感的问题上，但往往不是这样。 我们经常在初始化界面时要根据权限设置可见和可用，用了一堆的if语句，在业务层也要根据权限判断是否继续执行接下来的代码，同样验证也是有一堆if语句。每当写这样的程序时脑子里要想到有那些东西要设置权限，是可见还是可用，是那些关系表达式的组合，生怕漏掉或是写错任何一个。当发现错误时我们得看着长长而且相似的代码一时找不到错误的位置。虽然这些工作很简单，但很快会有人说：“嗯，这个地方需要改进。” 给窗体设置内容时一个一个控件的选择，在属性中设置各个参数。特别是表格控件需要对每个列设置文本值各参数甚至还有事件，代码中可能还有权限。它需要一个一个的来，一会儿是复制张贴一会儿是鼠标选择焦点，切换来切换去会让思维停滞或转移，区区的零点几秒累计起来可是不小的数字。似乎我们的很多代码不是写出来的而是画出来的，除了直观没有其他的好处，这里不是否定可视化，可视化的操作也是产生代码的，只要把结构设置好，内容是可以根据业务层的数据自动完成的。 还有操作，我们要添加很多事件去调用业务层的方法，如果业务层没有你要的方法就要去业务层加个，似乎界面层上的控制是事先知道业务层的的相应方法是做什么用的，耦合度问题？ 问题分析和解决 对于MIS系统会遇到一下几个东西：结构、内容、权限、验证、流程、操作和数据。 结构：好比框架，一块一块的区域。 内容：结构中的内容，一般是控件。 权限：我们总是用分支语句来做权限上的事，每个分支语句其实都可以看成一个关系表达式或关系