谈谈我的一点粗浅认识:
“企业对象分功能对象、数据对象、实体对象其中功能对象又可分控制对象、
协调对象、交易对象等”。
我认为企业中间层对象应该从OO的思想和软件分层设计思想结合企业业务逻辑去考虑。
至于组件模型、各种Pooling技术、负载平衡、数据传输(如:XML)等方面,是
计算机技术架构的问题。
先说说一个简单应用的三层结构,应用服务器使用WebLogic,WebLogic通过jdbc
访问Oracle。我们在WebLogic上面建立了若干SQL访问的对应,我们称之为“Service”
,客户端通过调用不同的“Service”,提供不同的参数通过XML(HTTP协议)格式
请求应用服务器。这确实是真正意义上的三层结构,客户端与数据库服务器完全隔离。
但是并非OO的设计。
下一步,我们打算建立一般的可重用的数据库访问组件,我们称之为“DataGate”,
当然我们采用OO的设计思想。在这里,我们为了复用和灵活,设计一个数据对象生成器
(DataObject Designer),可以自由添加、修改、删除数据对象,每个数据对象包括
属性(对应用数据结果集中的字段 *注意不是数据库中的字段)和方法(对应用数据库
访问方法,表现为SQL语句或procedure等)。当然数据对象串行化为XMLdo
cument。
当客户端访问DataGate时,上传包含了引用的对象名称,调用的方法,参数等等的XML标准
数据格式(有点像soap?),DataGate通过解释XML,按照DataObject Designer中设计的
数据对象和相关的访问数据方法访问数据库服务器,当然可以返回XML的结果集。
然后,如果有业务流的应用系统可以设计一个业务流对象生成器(Business flow Designer),
以每个业务点为对象设计为相应的业务节点,业务流就是各个业务节点(business node)
的不同组合。当然也使用XML储存节点对象和业务流程关系,应用层通过解析业务流XML,
执行相应业务代码,使用或生成相应的操作界面。
然后....
我就不再卖弄了,因为我对企业应用几乎没有任何实践经验,理解甚浅!
只是为了抛砖引玉,希望能听到真正内功深厚的大侠讲道。