使用oo和不使用orm并不矛盾, 业务实体不一定都在数据库里, 并且转换一下也并不麻烦.
现有的关系型数据库搞了几十年了, 积累了丰富的资源, 全部重来是不现实的, 追求纯粹的oo是没有意义的.
使用orm通常意味着数据库表设计的原则发生了变化, 目前, 数据表是很多系统的通信方式, 这样的情况下, 推广使用orm是比较困难的.
不知道各位有没有成功的经验.
实际工作中倒是觉得推广一些新的技术的时候, 最大的障碍来自观念上, 一种观念是: 技术是无关紧要的, 无论怎么做, 只要达到需要就可以了,
不必在新的技术上花时间. 另一种观念是: 采用新的技术 会增加系统的复杂程度, 可能会增加不确定性, 目前的技术尽管是至少是quick的,
可以立刻投入人力看见进度.
 On 4/22/05, idior <xuning....@gmail.com> wrote:

On 4/23/05, 陆海涛 <lane...@gmail.com> wrote:

至于对旧有系统进行ORM，并非不可，只是受到的约束太多。在考虑旧有系统的兼容性和数据的迁移上，很多时候，我们会感到束手无策。要么就是工作量太大，使我们 鼓不起勇气来下这个决定。

对于旧有系统，是否进行ORM？如果评估了需求，有必要去做的话，通常项目经理面对的难题，其实就是长痛与短痛的问题。如果不采用好的架构，重新设计，那么面对 不断涌现的新需求，开发人员只能象救火队员那样，疲于奔命，最后导致的是版本与bug同飞，需求共文档一色，乱七八糟，带来的痛苦是长期的。
如果彻底洗牌，全盘来过。那么时间就成了悬在所有成员的"达摩克利剑"。在客户与产品经理的催促下，新设计的项目架构，是否真能解决所有的问题？无论是稳定性、 扩展性还是安全性？

总之，这一切首先不是技术的问题，而是业务的问题！很多情况下，可能我们是无能为力去做抉择的。

感觉还是观念上的问题。

我们的项目组是从PB转到.Net上的，现在更多的时候是从"面向数据"的角度而不是"面向对象"的角度考虑问题，很多事情不是简单说一说就能扭转过来的。

传统的设计方式是面向过程的, 其内涵是对一个业务行为进行过程上的*分解*, 将一个大的行为分解为多个小的行为, 从中发现各个行为的共同部分, 复用其代码,
这种设计方式的前提是, 对各项业务实现的*具体过程*已经有了较充分的了解, 否则业务的分解必然是错误的. 一旦业务的实现方式发生变化,
带来的改变也比较剧烈, 因此, 这样的设计方式对需求变化的适应能力是有限的.

采用面向对象的设计方式, 首先要对具体的业务功能进行*抽象*, 从原理上看, 事物的抽象程度越高, 其正确性的保证就越大,
一个完全抽象的事物是不可能错的(比如把一个订单抽象成一个Object,肯定是对的), 完全抽象的事物当然也没有什么实际用处,
抽象需要进行的程度取决于可以预料的变化, 抽象到可预见的需求都不会对其发生冲击就够了, 从需求认识的规律上看, 一般了解一个需求是先了解一个整体的概念,
然后再具体的了解细节, 是从抽象到具体的. 最初的系统设计应该是基于一系列抽象的对象, 在这个基础上, 进行最基本的实现, 实现第一次交付,
然后加上新的实现, 不断增量开发新的功能.

系统中的各个模块是在抽象的层次上依赖别的模块, 因此, 具体实现的变更是完全隔离的. 在系统开发的过程中, 可能会发现最初的抽象模型是错误的,
或者不满足新的业务, 或者不可能实现(一般是由于性能方面原因). 这个时候, 接口的约定可能会发生变化, 接口之间依靠约定互相作用,
因此这样的变化会扩散到多个模块. 这是最不利的情况. 实际情况下, 即使是一个十分庞大的系统,
其某个抽象层次上的类型数量也十分有限(比如tomcat,核心的抽象类型不超过10个), 因此, 这样的改动也是相对可行的. 采用这样的设计方式,
系统的框架是有可能发生渐变, 甚至突变的.
On 4/28/05, idior <xuning....@gmail.com> wrote:

On 4/29/05, 陆海涛 <lane...@gmail.com> wrote:

On 4/23/05, 陆海涛 <lane...@gmail.com> wrote: