关于MIS系统的类和函数的处理(200分)

  • 主题发起人 主题发起人 zysea
  • 开始时间 开始时间
Z

zysea

Unregistered / Unconfirmed
GUEST, unregistred user!
一般复杂一点的ＭＩＳ系统的业务处理过程都比较麻烦，用户输入的结果数据集可以要经过
多次判断加工再形成不同的结果存在数据库。
若用类来描述业务，如果一个业务逻辑太长，就有可能使多个类的多个方法都可以处在
数据库的同一事务内！这样会让系统变得很复杂，怎样避免这种情况呢？
各个类的方法可能都会用到用户输入的结果或中间的加工结果，把结果数据集作为参数传
递这个方法好不好？有没有更好的？
本人以前没有系统的面向对象编程的经验，发现在ＭＩＳ系统中引入这些非常困难！
 
最好是把一些数据集的字段整理，分类，在此基础上定义各种不同的类，来描述数据集的
内容字段。
 
请各位高手踊跃发言啊！不然我２００分怎么送得出去啊！：）
 
使用UML建模
 
我觉得UML只是一种工具，如果没有理顺OO的思想，它根本就没有用武之地。
 
唉，200分啊，大家都不要吗？：）
 
无论是面向对象,还是面向过程，都是一种方法论，没有必要被这些概念所束缚。
其实大多数的Mis系统(至少我接触过的几个)并非是完全的OO编程模型。事实上我们做过的
项目中只有对于系统非常核心的部分才会考虑抽象出来作为类封装。
多说一句：完全的面向对象编程要求最后的系统要由类实例之间的交互来完成。但是这往往是
一种教科书式的完美逻辑。在实际开发中，由于大多数项目的资源有限（包括时间以及开发人员的
素质、前期项目需求是否完善等因素），往往很难全面的抽象出业务中真正核心的类，甚至有些
项目在开发初期连用况(Use Case)都未能分析全面。所以盲目的照搬OO只会适得其反。或者出现
多层的类继承，或者庞大的类定义等等。
个人意见：应当依据项目组成员对OO的掌握程度，逐级的在你们的产品线上推广OO应用。第一个项
目OO的比例可能要小一些但这没有关系，OO与传统的面向过程式的开发本来就不是冲突的。应用OO的
场合也并不一定就得架构于系统层(OOA)，也可以是模块级的。先从小的地方积累经验，等你熟练了
再尝试更大的应用场合（比如系统分析），这样通常可以使你逐步尝到OO的好处，而不至于因为最初
盲目应用OO而后来陷入泥潭并最终丧失对OO的兴趣。
 
非常感谢wolfxp从宏观的角度讨论了ＯＯ在系统中引用必须有一个 分步积累的过程。
我也还处在向ＯＯ深入的过程中，一般的和数据库无关的类还比较好抽象处理一点，
可是和数据库相关的类就感到处理起来非常麻烦，主要是要考虑事务和数据性能的
影响，因为用类来处理就存在可能一个事务中包含多个方法，要涉及多个类。而从数
据性能方面考虑的主要是有可能一个结果在多个方法中都要使用，而如果每个方法都
重新从数据库中ＳＥＬＥＣＴ数据的话性能显然不是很好。
可否就我下面的问题给一些比较微观细致的指导：
若用类来描述业务，如果一个业务逻辑太长，就有可能使多个类的多个方法都可以处在
数据库的同一事务内！这样会让系统变得很复杂，怎样避免这种情况呢？
 
拿分来吧，这种小mis我做的大把了，明显是要把业务逻辑分成许多com组件，然后放在com+的环境下就可以了，该环境
自动帮你维护事务。。
 
如果将对数据库的操作封装起来,业务逻辑中如果有关于数据库的操作就将其作为某类
的一个属性,然后在这个数据库操作类中进行优化处理,这样是不是能够减少系统的复杂性?
 
to delphi浪客:
COM我不懂，不过不管用什么做，总存在微观实现的问题，所谓的事务自动维护我不是
很明白，比如：adoquery1.post;adoquery2.post;adoquery3.post;有时候可能是三条都成
功才能全部提交，有时候可能是第一二步执行成功，就可以提交了，第三条无所谓，只是
要给用户一定的提示，那这种情况它是怎么自动识别的？如果还需要我在代码中指定是
属于哪种情况的话那这叫做自动吗？
扯远了：）我还是希望有人来从代码的角度给予指导，谢谢 大家！
 
多人接受答案了。
 
您必须登录或注册才可回复。

Similar threads

S
【教程】QJSON 创建根结点为数组的 JSON 内容
回复
0
查看
510
swish
S
S
[教程]程序保存数据的防断电处理策略
回复
0
查看
911
swish
S
不
奇淫怪巧之在Delphi中调用不申明函数 - 不得闲
回复
0
查看
876
不得闲
不
S
[教程]ZAsync 异步编程之四：请记住匿名函数是一个接口
回复
0
查看
699
swish
S
S
[教程]Lazarus 在 Linux 下中文输入法问题的临时解决办法
回复
0
查看
849
swish
S
后退
顶部