大家来谈谈企业开发中的模式的使用
idior
大家在实际的项目中如何使用o/r m?
如果不使用又如何充分发挥oo以及dp的作用?
希望大家能发表一下各自的意见.
陆海涛
idior
aop...@gmail.com
mapping更改旧有系统显得有些mission impossible的原因。
至于对旧有系统进行ORM，并非不可，只是受到的约束太多。在考虑旧有系统的兼容性和数据的迁移上，很多时候，我们会感到束手无策。要么就是工作量太大，使我们鼓不起勇气来下这个决定。
对于旧有系统，是否进行ORM？如果评估了需求，有必要去做的话，通常项目经理面对的难题，其实就是长痛与短痛的问题。如果不采用好的架构，重新设计，那么面对不断涌现的新需求，开发人员只能象救火队员那样，疲于奔命，最后导致的是版本与bug同飞，需求共文档一色，乱七八糟，带来的痛苦是长期的。
如果彻底洗牌，全盘来过。那么时间就成了悬在所有成员的"达摩克利剑"。在客户与产品经理的催促下，新设计的项目架构，是否真能解决所有的问题？无论是稳定性、扩展性还是安全性？
总之，这一切首先不是技术的问题，而是业务的问题！很多情况下，可能我们是无能为力去做抉择的。
Cobra Net
感觉还是观念上的问题。
我们的项目组是从PB转到.Net上的，现在更多的时候是从"面向数据"的角度而不是"面向对象"的角度考虑问题，很多事情不是简单说一说就能扭转过来的。
idior
陆海涛
传统的设计方式是面向过程的, 其内涵是对一个业务行为进行过程上的分解, 将一个大的行为分解为多个小的行为, 从中发现各个行为的共同部分, 复用其代码, 这种设计方式的前提是 , 对各项业务实现的具体过程已经有了较充分的了解 , 否则业务的分解必然是错误的 . 一旦业务的实现方式发生变化 , 带来的改变也比较剧烈, 因此, 这样的设计方式对需求变化的适应能力是有限的.
采用面向对象的设计方式, 首先要对具体的业务功能进行抽象, 从原理上看, 事物的抽象程度越高, 其正确性的保证就越大, 一个完全抽象的事物是不可能错的(比如把一个订单抽象成一个Object,肯定是对的) , 完全抽象的事物当然也没有什么实际用处 , 抽象需要进行的程度取决于可以预料的变化 , 抽象到可预见的需求都不会对其发生冲击就够了 , 从需求认识的规律上看, 一般了解一个需求是先了解一个整体的概念, 然后再具体的了解细节, 是从抽象到具体的 . 最初的系统设计应该是基于一系列抽象的对象 , 在这个基础上 , 进行最基本的实现, 实现第一次交付, 然后加上新的实现, 不断增量开发新的功能 .
系统中的各个模块是在抽象的层次上依赖别的模块, 因此, 具体实现的变更是完全隔离的. 在系统开发的过程中, 可能会发现最初的抽象模型是错误的 , 或者不满足新的业务 , 或者不可能实现 (一般是由于性能方面原因). 这个时候, 接口的约定可能会发生变化, 接口之间依靠约定互相作用 , 因此这样的变化会扩散到多个模块 . 这是最不利的情况 . 实际情况下, 即使是一个十分庞大的系统, 其某个抽象层次上的类型数量也十分有限(比如tomcat,核心的抽象类型不超过10个), 因此, 这样的改动也是相对可行的 . 采用这样的设计方式 , 系统的框架是有可能发生渐变, 甚至突变的.
感觉面向数据在国内还是比较普遍的.
lawrence liang
现在出差在北京，项目差点把我累死：（
先冒个泡，有时间我也参与到讨论中来学习学习
lawrence liang
On 4/23/05, 陆海涛 <lan...@gmail.com> wrote:
