请教面向对象的话,持久层设计有多大区别?

在JDON 逛逛,才发现自己以前用的方法都是面向数据库的。不过初步接触这些内容一时真无法理解。
但是如果面向对象为主的话,那数据库设计和面向数据库有区别么?我拿一个简单的blog 为例:

---------以前我数据库设计-----------
member: uid username password //用户表
roles: role_id role_name //角色表
member_roles: uid role_id //用户与角色 多对多
artical: aid title category content //文章表。 category 有 blog 和 studynote 分别代表日志和学习笔记

---------如果以面向对象思路的话-----------
对象:
class Artical{} //文章对象
class Blog extends Artical{} //博客对象,博客也属于文章。
class StudyNote extends Artical{} //学习笔记对象,学习笔记也属于文章。

interface ManageMyArtical_Behavior{} //管理自己的文章行为 CURD
interface ManageAllArtical_Behavior{} //管理所有文章行为 CURD
class ManageMyBlog implements ManageMyArtical_Behavior{} //管理自己的博客
class ManageMyStudyNote implements ManageMyArtical_Behavior{} //管理自己的学习笔记
class ManageAllBlog implements ManageAllArtical_Behavior{} //管理所有的博客
class ManageAllStudyNote implements ManageAllArtical_Behavior{} //管理所有的学习笔记

class Member{// 用户对象
ManageMyBlog managemyblog;
ManageMyStudyNote managemystudynote;
}

class Admin extends Member{//管理员对象,管理员也是用户。
ManageAllBlog manageallblog;
ManageAllStudyNote manageallstudynote;
}

-------------------------
这样设计的话,难道数据库设计有不同?
以这个例子为例,面向领域,应该如何设计呢?
请帮我从实例来解惑。谢谢各位了。

这种方式基本上不对。

LZ前面定义的接口基本上都是面向数据操作的,所以如果思考下去其实只能是包含一些数据库的操作,但这并不是面向对象的方式。

面向对象的设计从业务过程的抽象开始,说起来比较复杂了。建议去看一本OO的书,多数的书里面都会有一个或者几个实例的分析过程,体验一下再回来思考这个问题。

interface ManageMyArtical_Behavior{} //管理自己的文章行为 CURD
interface ManageAllArtical_Behavior{} //管理所有文章行为 CURD

这两个接口? 里面不一定是直接操作数据库。 不过定义了管理文章的方法。
----
OO我还是明白的,不过对于这样的web操作。 我还是跳不出要操作数据的框框。
那一这个blog 为例,应该如何设计呢?

迷惑了几天 也没人回答。
在论坛里面看到的帖子,都喜欢把问题说的极其模糊。
一下子哲学,一下子理论。或者说我不懂OO。
不是说这些道理不对,就是觉得好,我才想深入下来学习。
去下载了infoQ 下了 领域模型驱动 精简版。
也是从很高的程度来说明问题。立意这么高,看得人似懂非懂。
又没有例子可以从实践层度来提高我的认识。
真正坐下来,却不知道如何开始。
说到OO基础, 我也有几年的JAVA经验,设计模式也很熟悉了。
但不是每个人都是哲学家,学东西都是一边实践一边学习。学习来又要用于实践。

学ontology的时候,立意也很高,来自古典哲学本体论
宇宙的万事万物皆为本体。单单看这些道理,对我们学习有什么用?
但有经验的专家会建立一个又一个实际的本体,从简到繁,来提高我们的认识。

这里高手云集,希望能举出一些简单的例子来帮助我们学习。

楼主别心急,如您所说以前用的是数据库思维设计系统,现在希望转到oo上来,想法是好的,但是也有个不争的事实,现在国内大多数的软件公司还是在围绕数据库做系统,以功能实现为第一,而不是扩展性,可维护性为重。本站提供了很多oo设计的思想和具体实例,有待你慢慢查看。

空话谁都会说,可到实际做持久层时,恐怕还得面向数据库,至少在目前。

Banq应该出来好好的解释一下了。

不过LZ,有些信息是必须被持久化到数据库的。这点不可否认。但是,问题就是怎么样被持久化到数据库中。到底是为了持久化为持久化,还是为了模型而持久化。这样一来,思想就大了。如果一开始就想着持久化,那么必然就是从持久化开始了。如果一来想着领域模型,那么等需要持久化的时候在持久化。那个时候一切都以模型来持久化。自然总的思想就可以撇开数据库了吧。

但是,具体实现这个比较难啊。因为按DDD的思想来说,就目前这些常用的框架,SPRING,HIBERNATE似乎很难啊。

哎,Banq请拍砖,不过别拍的太厉害。我才大三,DDD的书买也买不到,还是从学校图书馆借的,也不打算还了。就5倍赔,算丢失了。

业务要考虑,数据存储也要考虑。我不相信靠框架的优化和缓存能超过人工对数据库的调优。