数据建模 vs 对象建模 (从Ofbiz帖子切分出来的)

大家对对象建模和数据建模好像有些误解吧。
    任何一个系统，最开始进行的应该是概念建模，把每一个业务概念理解清楚，生成相应的术语表和业务模型（业务模型由概念模型、业务规则、业务用例组成）。这个是需求分析该做的事情。
    然后到系统分析阶段，再将概念模型转化为数据模型和对象模型，数据模型和对象模型只不过是一个是数据库（物理层次）的描述体现，一个是计算机语言的描述体现。两者是对应的，而且都是必需做的。所谓建模，就是建立模型，用语言工具（包括数据库、计算机语言）的逻辑的描述现实中的复杂逻辑。
    我很奇怪楼主怎么会拿这样一个问题去讨论，这两者都是相关的，是不可分割的，并且是相互转化的。谁先谁后都不存在问题，反正总之都得在概念模型，也就是业务建模之后。
    另外，有的朋友说数据建模现在包含了对象的概念，这只是一种方式而已，用面向对象数据库当然需要对象概念，不过我们常用的只是关系数据库，这个时候，数据模型只是概念模型的一种实体存储表示，没有任何对象的概念，当然，一个实体表可以映射到对象模型中的一个类。

标题所说的应该是系统对象与数据模型吧,业务对象的抽象应该是在前面做的,而系统模型和数据模型谁先谁后应该问题都不大

我讲讲我现在的开发模式。
我的系统是基于struts的。
是这样的，首先需求分析，都调研清楚之后，设计表结构。然后根据表结构生成系统的框架，基本的情况是这样的。
系统中的，每个表都对应一个类，如EtpType（字段id,name）表，EtpType.java类，EtpType.java类中有
(protected int id = -1;
    public int getId() { return id; }
    public void setId(int aId) { id = aId; }
    protected String name = "";
    public String getName() { if((name==null)||(name.trim().length() == 0)) return ""; else return name.trim(); }
    public String getName(int size) { if((name==null)||(name.trim().length() == 0)) return ""; else if (name.trim().length() <= size) { return name.trim();} else { return name.trim().substring(0, size) + "...";} }
    public void setName(String aName) { name = aName; })

等方法。同时有一些方法如getByid();insert;delete;update及getCount（注：计算共有多少条记录的方法）和一些按条件查询的方法。

2>还有EtpTypeAction.java类，这是一个struts中的action类
3>还有EtpTypeForm.java类，这是和页面上的form 对应的类。

这就是我目前处理的方式，Form类取得数据，在Action类中处理业务逻辑，在action中调用EtpType类来进行数据的插入保存包括查询等。
看EtpType.java类中的update方法：
public int update()
    {
        String UPDATE =
                 "UPDATE tb_etptype SET id=?,name=? WHERE id=?";
        int iResult = 0;
        Connection con=null;
        PreparedStatement pstmt = null;
        try
        {
            con = DatabaseConnection.getConnection();
            pstmt = con.prepareStatement(UPDATE);
            pstmt.setInt(1, id);
            pstmt.setString(2, name);
            pstmt.setInt(3, id);
            iResult = pstmt.executeUpdate();
        }
        catch( SQLException sqle )
        {
            sqle.printStackTrace();
            return iResult;
        }
        finally
        {
            try {  pstmt.close(); }
            catch (Exception e) { e.printStackTrace(); }
            try {  con.close();   }
            catch (Exception e) { e.printStackTrace(); }
        }
        return iResult;
    }

如上，
pstmt.setInt(1, id);
            pstmt.setString(2, name);
            pstmt.setInt(3, id);
我们在向数据库中插入或保存相应的数据只需要实例 化EtpType,如EtpType etptype = new ......;这样，然后调用etptype.setId,.setName方法然后，调用其自身的update()方法就可以保存数据。

从前台页面form中得到数据，在action中处理逻辑，用Etptype.update或者.insert实例保存数据。这就是一个周期。
我根据大家的贴子判断，我的系统应该属于数据驱动建模。
系统中每个表都是以上的情况，在项目中我觉得能很好的满足我的需求。我不明白如果改成面向对象建模我的系统各个部分会发生怎么样的调整（注我很想知道）
我们的系统是属于业务系统，也就是说robbin说的，需求经常变化的系统，更好的方式是面向对象建模，但是我现在不明白，在面向对象建模中各个部分划分，也就是我上面的模型中哪部分要发生变化。vo,bo,pojo,等等，我还不是很明白。

我现在就是想知道面向对象驱动建模，整个体系是怎么构架的，举个例 子是struts + hibernate，是不是还是页面form取数据，在action中处理业务逻辑，那其他的部分是如何处理的，也就是向数据库中存是怎么处理的，是不是还是会产生一个象我上面系统中用到的和数据库同名的一个类如Etptype.java类，(这个类里面是不是还是有insert,update,query等方法?我估计好象不应该有了),那个EtpType.java是个类是不是个vo,也就是起到传输数据的作用的？？？
EtpType.java这个类会不会有，如果会有，他是什么作用，大侠能否为我讲清楚？我系统中的insert,update,query(用于复合条件动态查询)这些方法是不是会消失？如果不是消息了，它们的作用谁承担起来了？？？
希望能有好砖拍出来，把面向对象驱动，struts+hibernate体系中的框架讲清楚？我在期待

所谓数据建模和对象建模孰优孰劣的问题，没有讨论的必要。他们也不是什么VS的关系。存在就是有理。和使用人员的经历和目的有关系。

另外提一点，ofbiz ee 绝对不是数据建模。如果在定义的模型中包含了业务关系（如人员对部门的从属关系）的话，哪位认为这样的模型仅仅是数据模型？而ofbiz ee中定义的模型恰恰可以包含此类关系。

ofbiz ee 并不是一个纯粹意义上的orm。他也没有必要成为orm。这和ofbiz的定位是有很大关系的。关于这一点，离题太远，在下就不多说了。这一点我深以为然，够用就好嘛。可以这样理解，ofbiz ee提供了通用的简单对象，所谓通用的vo（这一点估计会有不同声音，但我自然有我的道理，诸位有兴趣的话可以另起专题讨论），然后通过管理器对其进行基本的持久化和查询，同时提供了cache和自动生成ddl并执行。他的cache机制十分稳定（在我做过的项目中没有发现问题）且比较灵活（如findByAndCache方式）。更加复杂的bo可以通过对其vo的组装来完成。所有这些功能的完成都简单可靠。

ofbiz ee 帮我解决了大约70％的持久化问题。剩下的复杂功能，我不得不依靠jdbc，sp和数据库调优来解决。这也是没有办法的事。

用OOAD还是数据驱动的开发方式会对概念建模产生影响

公司或开发组有必要对这个问题达成共识，不然连纯粹的技术争论都失去基础
还谈什么合作和开发？