有关领域对象

对于银行核心系统技术主导，还是几个技术领导加上几个技术骨干说了算，这些老大级别的人物都是在银行呆了上十年的，OO的概念比并不深得他们得心，他们是从C/ESQL这些开发语言过来的，他们天生对他们能够掌握，熟知，能够探究的技术比较把握，而对于层次相对比较复杂的OO还是天生“惧怕”的，不过，将C用的厉害的技术公司大有人在，上海的思群公司便是一个例子，里面有几个老大还是很厉害的，用C居然将OO概念用到极致，核心模块的关于 事务动态管理，模板方法＋动态函数调用 完美分离具体交易业务逻辑，日志管理，动态管理核心平台配置，可动态加入各种报文种类，交易具体实现等等核心开发平台，这些我都是大为感叹，能够使用C达到如此境界的，中国还没有多少个这样级别的人物！
不过，现在和将来 银行核心系统开发肯定采用C＋＋，以逐步推进OO思想。这是必然的！

围绕数据库为核心进行整个业务系统的开发，这种模式曾经非常流行过，我们在2000年做在线广告投放系统的时候也是这样做的，绝大部分业务逻辑都是Oracle的存储过程实现。在当时，OOAD的思维还没有被普及开来，即使在今天，又有多少人，多少公司真的能够良好的运用OO，而不是把Java当做过程语言来用呢？不过我觉得比较乐观的是，基本上我接触到的面临这些问题的公司都是自己非常有主观愿望想去改造老系统的，而且数据库管理员也一般不排斥，因为现在OO思想已经非常流行的，他们也不希望抱残守缺，也希望通过这样的机会，掌握流行的热门的新技术。而且他们维护这些老系统已经是怨声载道了，如果能有新的系统解决这些问题，他们实际上是非常愿意合作的。我接触过的3个案例，其中2个是愿意合作的，1个是比较顽固，不愿意合作的(不过下面的人怨言特别多)。

能否稍微展开，详细讲述一下如何对Oracle存储过程进行重构，如果用领域模型来封装存储过程呢？

哦，有点勉强哦！不同领域，不同业务规则，很难抽取共同点来说吧。不过对于这个问题，似乎那本martin fowler《分析模式》倒是可以一用阿。
如果potian愿意展开的话，我搬个凳子过来！

我没有完整地总结过。实体类是第一步。接下去的原则就是慢慢把存储过程的逻辑变为实体类中（或者是Manager，对于那些综合多个实体，不适合把逻辑放在某一个实体内的行为）的java逻辑或者变成ORM可以管理的实体关系。

核心就是拆分，把原先搞在一起的过程拆分为多个不同的过程，用统一的命名法，通常是类名+方法名。最基本的要素是OAOO，这有两方面的要求，一是数据库结构的normalize，还有就是一般来说，对同一个实体（记录）进行更新的代码必须在一个过程中，而不是分散到其他过程中。如果需要的话，必须有其他过程分派到这个过程来实现（查询有可能不能完全做到），

对于具有引用关系的实体，定义一个通用的存储过程系列，例如对于1：n关系，通常是根据主id和1的表名字和n的表名字，获取子集合，把一个子表的名字，id和父表的名字、id等等进行维护操作。存储过程使用动态SQL语句来完成，这些代码最终将被全部清除，因为它们是ORM管理的东东。但第一步变成Java代码的时候，用classname作为参数就可以直接建立java代码和存储过程的关系。

如果一个两个过程之间需要大量传递一个记录的很多字段，那么过程之间采用Id进行交换，让对方重新从ID获取数据。以后将变成对象之间的引用，如果直接是普通参数，那么成为方法的参数，最终的目标是对于某一个类的处理通过重构移到同一个类名为开始的不同方法中

子类和父类的方法在过程中还是用用标志，但是对于不同标志造成不同行为的过程使用过程别名、例如CLASSA_METHOD1_A,CLASSA_METHOD1_B等等。java代码中继续使用标志参数，但是可以根据不同参数值分派到不同的方法

最后形成的结果就是基本上没有继承层次的一批类，类的每一个方法对应一个存储过程，类的交互通过对象参数正好能够翻译为用Object.getId去调用存储过程。

当这样的包装成功以后，我们就可以进一步在Java层次上进行重构，例如把标志判断变为子类，应用各种重构模式，并把它慢慢反作用到存储过程上去。最后存储过程的代码越来越少。直至变为简单的delete,insert和update为止（除了需要联合的查询）。

Oracle的存储过程，我都没搞清楚，看这个咚咚，象天书一样~~!真是惭愧阿。
完蛋了，没了讨论权利啦。

谢谢，已经讲的非常清楚了，剩下的就是去实践了。

我现在到是觉得，做数据库存储过程紧密耦合系统的改造咨询，应该很有市场，呵呵。现在如果完全重新开发的话，成本太高，而且失败的可能比较大，又没有办法重用很多原来的东西，如果可以按照potian介绍的这种办法，通过对存储过程的重构，存储过程和Java Class建立映射关系，一步步的把存储过程紧耦合的系统改造为面向对象的松耦合系统，这样的咨询业务还是有蛮大的市场的。

对OO都是数据和方法混合体的这种观点，我觉得是陷入了一种误区中了。

OO只是说使用面向对象的观点，并没有规定只有数据和方法混合才有资格称为对象。随着问题领域的不同，OO会发生不同的强化和弱化，以适应不同事物的对象层次和对象粒度。对那些只包含数据的事物，确实可以抽象成只包含数据的对象，而且也应该抽象成只包含数据的对象——这是合情合理的。

对象可以分成主动对象和被动对象，对于被动对象，高效地组织数据关系才是它们的根本使命，如果你把主动对象的行为强行加到被动对象上来，你其实是破坏了被动对象的被动特性，同时也破坏了主动对象的主动性。这样一来，你在后续的设计中设计你的继承体系时就会出现混乱，会把不必要的关联牵扯进来，这也是面向对象系统体系结构开始崩溃和混乱的开始。

想想你们推崇的MVC，它把表示和数据分开是为了什么？你是不是要它把数据和方法混在一起才觉得这才是面向对象？保持对象的最小粒度，比固守着对象就是要数据和方法结合在一起的观念来得重要。况且现在似乎也有方法对象的概念，既然如此，纯粹的数据为什么不可以成为一个对象？

MVC从来没有说搞一个只有数据的哑对象。M是model，就是应用的领域对象，业务逻辑都在里面；controller只是运转输入输出，不处理业务逻辑。

嗯，看来是我误解了MVC。我举的这个例子看来不恰当。

我重申一下我的看法： 根据应用层次，OO的设计应该坚持当前应用层次下最小粒度的原则，不要让自己某些固执的观念妨碍了这个原则的实施，这才是我们应该做的。因为这个原则才是OO所要求的，其他的则有可能只是宣传的结果，并非OO的精髓。