COM+组件的结构（应用于进销存系统），实践中。。。

Question

我现在在做基于组件的进销存系统，第一阶段看了李维的书做了初步测试，第二阶段做了概要设计和详细设计的一部分，现在第三阶段计划用销售部分做组件设计测试，成功后整个系统采用。我一直没有确定下来组件之间的最佳结构，所以先描述一下现有的结构，以供大家评判：
第一层：数据访问对象：DO；
第二层：业务对象：BO；
第三层：协调对象：RO；
第四层：控制对象：CO；
下面逐一说明：
1、数据访问对象：DO。
功能：访问数据库。所有对数据库的读取更新都通过调用这个组件的相关方法。
事务：支持事务。
2、业务对象：BO。
功能：实现独立业务对象的所有功能。例如：销售单业务对象BOSaleOrder：方法包括读取单据列表；读取指定单据的详细信息；保存单据；删除单据；更新单据状态，审核单据等。
注意：销售单对象只实现那些影响自身数据的功能。比如审核单据方法不会实现记录日志这个功能。
事务：支持事务。
3、协调对象：RO。
功能：按是否需要事务分别实现业务对象的业务功能。例如：销售单协调对象ROSaleOrderUpdate（需要事务）的方法：审核单据包括几个步骤：A:销售单业务对象.审核单据；B:仓库业务对象.更新应出库数量；C：日志对象.记录操作日志；
销售单对象ROSaleOrderInfo（支持事务）的方法：读取指定单据的详细信息包括几个步骤：A：读取主表记录；B：读取从表记录；提示：所以一个业务对象都会有2个协调对象：需要事务的对象（更新数据）和支持事务的对象（读取数据）。
4、控制对象：CO；
功能：将业务对象的操作整合，同时又避免启动不不要的事务。例如：销售单控制对象COSaleOrder的方法：审核单据包括几个步骤：A.销售单数据有效性检查（支持事务）；B:销售单协调对象.审核单据（需要事务）；
事务：支持事务。
说明：使用CO也是逼不得已。设想一下：客户端要审核一个销售单，系统应该又一下步骤：A：检查数据（可能会出现提示，要用户提示是否继续；如果检查不通过，终止执行）：B：真正进行审核。
以上是我探索的组件结构，有些描述可能不清楚，所以给了一些例子说明，还有不清楚的地方，希望各位批评，讨论。

Answer 1

大家难道对COM组件架构的实战不敢兴趣！？

Answer 2

to One_Two:
我讨论的是组件的结构问题，即组件之间的调用问题。如果如果一个业务逻辑由一个独立的组件完成，那怎么体现出组件的复用性？

Answer 3

to One_Two:
公用的部分我会作为一个独立的组件，例如数据访问组件（DO）。任何要访问数据库的组件（如业务对象BO）都要引用这个DO。这样对象的独立性增强，耦合性降低，从而体现了复用性。所以即使DO访问的数据库由MSSQL换为Oracle，只需要修改DO就可以了（大部分情况下），BO、客户端不做修改。

Answer 4

我举例说明DO（数据访问组件），BO（业务对象），RO（协调对象），CO（控制对象）的作用。例如要实现销售单对象的审核功能，需要以下对象和方法。
一、DO
DO：数据访问与修改。方法：DO.UpdateData（更新数据）。
二、BO
销售单BO：实现销售单数据的访问与修改。方法：销售单BO.UpdateCheckStatus（更新审核状态）。
库存BO：实现库存数据的访问与修改。方法：库存BO.UpdateWaitOutQty（更新待发货数量）。
日志BO：记录日志。方法：日志BO.SaveLog。
三、RO
销售单ROUpdate（需要事务）：实现销售单业务的所有更新功能。方法：销售单RO.Check（销售单审核），调用上述三个BO的方法，步骤如下：1、销售单BO.UpdateCheckStatus（更新审核状态）2、库存BO.UpdateWaitOutQty（更新待发货数量）3、日志BO.SaveLog。
销售单ROInfo（支持事务）：实现销售单业务的所有查询功能。方法：销售单RO.BeforeCheck（销售单审核前检查）。
四、CO
销售单CO（支持事务）：实现销售单业务的所有功能。方法：销售单CO.审核，调用上述二个RO的方法，步骤如下：1、销售单RO.BeforeCheck（销售单审核前检查）2、销售单RO.Check（销售单审核）。
五、客户端调用：
销售单CO.审核。
我想我把我得思路已经讲的很清楚了，希望各位批评指正，参与讨论。

Answer 5

收藏！
很感兴趣，
1 李为的书里说了为软推荐使用无状态模式，是吗，具体到底有什么区别呢，我还没搞明白
2 好象你的组件似乎用的很多，单单一个模块就用了这么多个组件，那假如整个系统用下来，要多少个组件？除非这几个组件还能有大量的复用，否则我觉得太多了！
3 用Activity图来描述可能对你如何设计组件之间的关系比较有用！呵呵，一家之言！

Answer 6

也可以到
http://systemer.51.net/cgi-bin/topic.cgi?forum=4&topic=30&show=0
继续讨论！
我非常感兴趣！

Answer 7

这么多组件的作用在于：
1、功能独立。
2、基于1，所以利于复用。
组件多不要紧，在COM＋环境内部调用是很快的，而且耗用资源也不多。

Answer 8

你的思路是对的，但我现在想问你
假如我现在在中间层这样来定义
const 
   QryString = 'select * from Employee' ;
我假定其他的条件是有的，你怎么来把这样的一句传到客户端，

Answer 9

在李维的《ADO/MTS/COM+》书中关于MTS/COM+/Midas编程中不是有推荐的结构吗？难道这样的结构不能满足你的需要吗？
请回答一下，我也好再思考一下

Answer 10

to one_two:
不明白你的意思，“这样的一句”是指什么？
to alaclp：
其实我主要参照那本书上的结构，再做了一些变通。我不是说这种结构不能接受，而是大家切磋一下，看看我的这个结构的优缺点。
我现在打算去掉第四层（控制对象）的封装，冗余太多了。

Answer 11

我的EMail：[email protected]，有兴趣的同仁来信探讨，来信主题请注明：COM＋结构探讨。不能保证来信必复，抱歉。

Answer 12

组件太多是有问题的com+创建组件极慢。结构是很合理的，但现实中很少有人这么做。无状态的设计会很严重的影响到设计，因为池化组件没法在两次方法调用之间为你保存组件的状态，不能做任何状态的假设。我觉得最重要的是两类组件，控制协调组件（Control, coordinate, facade）和业务组件(Business)，而数据访问组件可以让ADO代劳。Client----SalesFacade----SalesServer
                               |
                               |
                         CustomerFacade----customerServer
还要很好的划分子系统的边界。

Answer 13

to pploveshao(阿水) :
你认为业务组件和数据访问组件应该合二为一吗？即每个业务组件都有直接的数据读写能力。这样的话，就可以在Delta数据包更新前写事件来做相应的工作。否则，象我现在这样的结构，只能等Delta更新到数据库中以后，再使用SQL语句执行相应的更新。