在学习中的一点疑问。

最近在学校图书管看了一些书,
项目都是围绕数据库的。
先写几张表。然后设计数据库。把表写到数据库里然后有的写存储过程。
然后再写jsp ,javabean。现在不是围绕对象了吗?
比如把一个Person 写成一个对象。
public class Person{
private String name = null;
private Integer age = null;
private Integer age = null;
public Person() {

super();

}

public Person(String name) {

this.name = name;

}

public Integer getAge() {

return age;

}

public String getName() {

return name;

}

public void setAge(Integer age) {

this.age = age;

}

public void setName(String name) {

this.name = name;

}

}

既然把user写成一个对象了那以后围绕这个person写为什么在数据库里还要建个表呢。那最后是围绕表还是围绕对象呢。这涉及到数据的持久化什么的吗?java语言和oo是相铺相成的那用java这种面向对象的语言和面向过程的那些数据库结合是不是有点象马和驴结合在一起呀。呵呵。开个玩笑。那既然要学面向对象那些围绕数据库开发的项目还看不。
如果结合oo是不就要学习ejb抛弃掉围绕数据库编程然后学习ddd建模使用uml。
我很疑问做一个面对对象的项目的流程是什么呀。由于接触java不久知识体系还没形成。说的话也许很片面也许很多地方想的都不对。语言也不是很连贯。望大家体谅。望告知做一个面向对象的项目的具体流程。谢谢大家了。

[该贴被scout于2008-11-27 16:14修改过]

自己多看看书,多做些项目吧

你的思考方向是对的。

在现有的软件理论中还没有能够提出完美的“对象”持久化方式,Java的序列化只是功能不是完整的持久化方案。

不过无论何时软件开发的过程中总会有一些“脏活”,就像Java里面的System.xxxx那些东西,不能完全的用OO来描述,现在的环境中数据库的操作过程就是这样的。ORM就是来帮助我们解决这些问题的一种方案。限制于现有的数据库理论全都是以“关系型”为基础的,所以现有的方案中还是有一些看起来不完美的地方,没办法我们职能忍受了。反过来OO提出了封装的解决方案,正是指导我们如何将这些“脏活”封装起来,尽可能的享受一个完美的世界。

建议你在看书的时候要有选择性的看书,不要选择那种没有内涵书籍(比如说*刚的书),要多学习作者的面向对象思想的内涵,你说的这种方法是面向过程的,是一个披着面向对象羊皮的狼,还有,如果有能力,多看看原版的数据吧

这个Person实现完全是一个数据集和,他的作用只是在业务过程间搬运数据.

换一种思考方式在get和set的接口上写一些JDBC或者Hibernate的方法操作数据库,再或者调用JCR,这样就是一个DAO的样子了。

再继续,如果这个Bean可以描述一个人在某些特定环境下的业务过程.比如作为一个翻译的时候,相应的增加一个接口translate(Object material),那么这个bean就可以提供翻译的功能了。这样已经开始面向对象了。这样的东西已经开始超越bean了。

单独看一个bean我们主要希望他提供的数据服务能力,所以才主要包括这些单纯的set和get。但是bean只是整个业务过程中的一个环节用于封装数据,整个业务过程的核心并不是在调用get/set修改这些数据而是描述一个业务过程。这样看起来bean为我们提供了OO中的封装,针对于数据读写的封装。

也就是说在现在这个大环境下只能是orm实现了数据和对象的mapping然后用hibernate等等框架来实现数据的持久。然后把person增加接口翻译,治疗等这样这个person就上升到了业务层了。业务层的核心在与调用别的方法了。可以在person里写别的方法调用这些方法?还是在上升到业务过程后get/set方法的意义也就随着上升啦。不知道我这样理解对不?

业务层是一个大的范围,根据业务的细化其中还是可以再进行分层的。

针对于Persion这个对象,它描述了整体业务过程中“一个人”的业务范围,比如translate()这个接口就描述一个翻译能够提供的“翻译”业务。

考虑一个实际的业务场景比如在一个翻译公司里面,如果一个persion描述了一个专职翻译的员工,那么会有个类似Corp的对象来调用Persion.translate()接口完成整个的翻译流程。如果继续扩大业务过程Corp也只是业务过程中的一个环节,比如一个客户提交需要翻译的任务,Corp控制进行翻译工作,完成的结果要还给客户,在这样的过程里显然需要一个更大的模型来支持业务过程。

再回来看看Persion,一般以如下的形式
class Persion
{
ORM/DAO dataAgent;

public Object translate(Object material)
{
// TODO do translate
}

public Object getXXX()
{
return dataAgent.get(xxx);
}

public void setXXX(Object xxx)
{
dataAgent.set(xxx);
}
}
在这里Persion.get/set 的确已经脱离了单纯的数据i/o上升到了一个业务的高度,虽然他的实际操作可能没有改变但是所描述的含义已经发生了彻底的改变了。

谢谢你的讲解,听了很有启发。

如果真的有帮助我也很高兴的