困惑,尴尬, 使用了公司平台,感觉在写面向过程的代码

07-06-12 gltbeyond
banq大哥, 诸位兄弟姐妹们请指教.

我们公司是做银行渠道整合的,成功的系统做的很多了,不敢妄言公司的平台有设计问题...

因为我们的平台就是copy或借鉴ibm wsbcc平台的, 核心交易流程,数据格式,交易数据... 之类的都是ibm的原样.

现在我们做系统时,主要在写业务逻辑时,感觉不到面向对象的特点,当然wsbcc框架是面向对象的.

交易的执行都是通过 Operator 配置文件配置的, 唯一要做的就是 写个POJO extends 交易bean, 写好回调函数. 这样很好.

没有面向对象的感觉,是指 大量的if-else在这个交易bean中. 3000行以上的POJO到处都是, if-else 的嵌套层次有超过6层以上的..

当新的需求来时, 就直接加个if-else判断...

访问数据库也是这样, 直接在POJO中写SQL语句,调用一个对 DB Access的简单访问包装类,更不提面向OO的数据库了.

可能因为系统的历史原因吧, 整个系统,没有看到几个业务域对象, Customer, Branch,Account ... 不超过10个吧... 有悖我们现在的BO设计规则, 一个面向对象的系统设计,应该从业务域抽取对象,对象之间的关系--关联,继承,组合,聚集. 这些都没有体现出来. 所以导致了我们现在感觉在些 面向过程的代码, 就是从面向关系的数据库中取数据,用if-else来处理业务.

一个面向对象的框架 被用来写面向过程的代码???

[该贴被gltbeyond于2007年06月12日 21:44修改过]

                   

gltbeyond
2007-06-12 23:41
ibm wsbcc框架基本上可以实现SOA架构,只不过这个soa是系统内部之间的联系,如交易配置xml.

SOA: 业务的需求描述成服务,服务由原子服务组成,原子服务是可以重用的. 业务需求变化了,只需要调整服务的定义,仍然可以使用原子服务.

--> 服务向业务看齐.

banq
2007-06-13 09:42
>一个面向对象的框架 被用来写面向过程的代码

框架的面向对象有两种:

1. 框架内部使用面向对象设计

2. 约束框架使用者使用面向对象设计。

很显然,在Evans DDD没有出现以前,所有的框架都是第一种,而没有第2种。

我以前说过,这也是EJB3 Spring等框架需要补的课,当然JdonFramework和RoR是第2种类型。

SOA目的和OO一样,但是不是同一回事,两条路。

gltbeyond
2007-06-13 13:45
谢谢banq指点.

框架/平台没有限制开发者使用面向对象的方式来使用,有空了请banq大哥讲讲一个系统/框架在设计之初,如何约束使用者也使用面向对象的方式来使用?

我们现在的数据大多以String,原始类型 放在Context中,没有Object之类的...

很多可以建模为对象的东西,没有去做,尽以String的方式散放在公共环境变量中,这纯粹是面向过程的方式.

框架要尽量通用,所以,业务域对象在框架中是没有的,框架只提供交易运行环境,数据容器,数据格式,通讯etc.

有空了请banq大哥讲讲一个系统/框架在设计之初,如何约束使用者也使用面向对象的方式来使用?

[该贴被gltbeyond于2007年06月13日 13:46修改过]

banq
2007-06-19 15:29
>一个系统/框架在设计之初,如何约束使用者也使用面向对象的方式来使用

主要需要有面向对象的思想指导,2004年以后有Evans DDD就是属于一个方法思想。

也可以在原来框架基础上再升华,如Spring+Hibernate也不能约束使用者也使用面向对象的方式来使用,所以才有MDSD,TSS最近介绍了这方面一个工具Sculptor,可生成spring+Hibernate多层架构代码:

http://www.theserverside.com/tt/articles/article.tss?l=ProductivityWithSculptor

Jdon框架当初设计时也有这个目的,强制性不强,可以参考其源码。

猜你喜欢