一个想法，不知能否实现。

10-05-24 tianqiq

java是面向对象的，但是现在很多的java系统全是面向过程的。为什么？我觉得一个很重要的问题。

是因为是因为我们大部分系统都是数据库系统，基本上就是crud。这束缚了我们的思维。使我们在碰到一个问题

的时候，总认为，建立好数据库，然后对应的model 然后crud。或者再添加一些复杂点的 crud就完事。

这不能说是错了。应为这样看上去非常直接，而且也确实能够做出系统。那怎么才能解决这个问题，

使我们不再关注数据库的curd呢，而关注我们领域模型呢。我觉得最好的办法应该就是忘记crud。

使我们的系统中根本就不存在crud的操作。可能有人会说那我们的系统数据怎么持久化呢。

其实我说的是，我们的系统不存在crud的操作，并不是说不要数据库了。

我的想法就是。我们能否开发一个框架，他管理着我们所有的对象，当我们需要对象时，我们可以向他拿，

当我们不需要这个对象时，我们可以告诉他，叫他销毁。当我们的对象属性，改变时。他会在你完成改变的的

时候，自动同步到数据库。说白了。就是一个能生产和跟踪我们的每一个对象，他自动的同步到数据库。

让我们在系统开发中感觉不到curd的存在。使我们更好关注领域模型。

不晓得我这个想法，能否实现。呵呵。

banq

2010-05-24 14:52

是一个好的想法。

key-value之类的NoSQL应该可以实现数据存储和可伸缩性，或者如MemoryCache + MemoryDB之类，但这些技术也只是针对散乱的数据，没有集中到对象封装上。

crud概念确实是针对数据库存储来讲的，潜在的语境就是面向需要的存储的数据，创建就是插入新增需要存储的数据，删除就是删除已经存储的数据，所以CRUD操作不是围绕对象的操作。

CRUD不是针对对象的，所以，在对象世界就可能没有对应的CRUD操作，也就可能无法找到对应相等的替代品。

如果是这样，那么围绕数据CRUD也可能有存在价值，简单系统，而复杂系统则使用OO。

spawnyy

2010-05-25 11:38

感觉是很不错的，应该是围绕对象模型来思考问题，可以实现可以监听整个模型，这里可以引用Observer模式，在模式的某个属性发生变化后，驱动Event来进行更新操作，不知道是不是就可以此方法了呢

banq

2010-05-26 08:50

2010年05月25日 11:38 "spawnyy"的内容

应该是围绕对象模型来思考问题，可以实现可以监听整个模型，这里可以引用Observer模式，在模式的某个属性发生变化后，驱动Event来进行更新操作，不知道是不是就可以此方法了呢 ...

JavAte框架就是这个原理，表现层使用ZK javascript框架，监听模型的变化，这种模式架构类似SWING架构，通过引入jgroup，也可以把事件触发分布化，5年前也就有类似框架。

cray

2010-05-27 09:32

我想知道, 一个框架管理所有的对象, 需要多少的内存, 每次修改都同步到数据库, 又需要多少的IO操作.
是否需要自己的框架管理Transaction, 框架又怎么處理Transaction Rollback的問題. 這樣, 框架是不是使用大型的項目呢?

my3bit

2010-05-27 10:29

感觉楼主是在说Hibernate

redorange

2010-05-27 11:29

2010年05月27日 10:29 "my3bit"的内容

感觉楼主是在说Hibernate ...

我觉得楼主的想法很好。既然面向对象设计与关系数据库存在天然抗阻，那么为什么不让数据库对象化。
Hibernate可以实现数据库对象化的效果，是关系数据库现有功能和用法的改进和延伸。所以它受到了极大推崇。
当楼主的想法似乎并不是Hibernate方案，而是希望数据库能理解对象，实现对象操作，前台只是获取后台的成果。这样数据库可以多样，前台语言也可多样。实现了处理的对象与数据库、编程语言皆无关的超然境界。
与Hibernate的区别在于，Hibernate需要编程语言定义对象，再由它转为数据库方式存储。现在是反过来了，由后台定义对象，再由它提供给编程语言。这时，编程语言并不一定要求是支持OO的了，任何语言皆可享用。

据我了解，对象数据库正向着这个方向前进。

redorange

2010-05-27 11:41

2010年05月27日 09:32 "cray"的内容

我想知道, 一个框架管理所有的对象, 需要多少的内存, 每次修改都同步到数据库, 又需要多少的IO操作.
是否需要自己的框架管理Transaction, 框架又怎么處理Transaction Rollback的問題. 這樣, 框架是不是使 ...

我来回答一下：
1、框架里的对象不一定都在内存中。
2、每次修改不一定要同步到数据库，当需要同步时，再一次性同步也不迟。
3、IO操作不用多，不需要类似Hibernate的懒加载机制来协调，框架应该能提供点菜式服务，即需要哪几个属性就下载几个，而不是一上来就整个满汉全席。
4、事务处理也是没有问题的，框架能提供历史值保存。可以做到随时roolback，不管是否操作失败。如果按照我曾经说过的信息唯一性原则来设计对象，根本就不需要roolback。
5、不需要大型数据库支持，因为已经解决了roolback、视图、储存过程等一系列问题。实际上，我认为这些新奇的玩意儿是对关系数据库不能正确认识世界的弥补，与对象化的后台没有任何关系。

cray

2010-05-27 12:11

2010年05月27日 11:41 "redorange"的内容

我来回答一下：
1、框架里的对象不一定都在内存中。
2、每次修改不一定要同步到数据库，当需要同步时，再一次性同步也不迟。
3、IO操作不用多，不需要类似Hibernate的懒加载机制来协调，框架应该能提供点菜式服务，即需要哪几个属性就 ...

关于1, 如果不在内存的话, 要放到哪里? 希望能提供解决方案, 而不是说理论上的可能性, 我觉得有点笼统.
关于2, 什么时候是需要同步时? 数据量大的话, 我不认为一次性同步会比多次好, 又怎么处理大量数据同步时中间的容错性? 不及时同步的话, 当用户使用到相同数据时, 是不是会出现脏读的情况呢? 这些应该怎么解决? 而且optimistic locking的问题, 又会怎么处理?
关于3, 也是希望提供方案, 怎么做到需要哪几个属性就要哪几个属性? 那view那一层, 开发者又得需要去看, 我拿的对象是不是缺少了些属性?
关于4, 框架提供的历史值保存, 保存在哪里? 不明白.
关于5, 我不认为框架跟数据库的大小型有关系.
另外你的rollback打错了. 哈哈

redorange

2010-05-27 14:32

很有趣的问题，我们可以这样设想吧。
首先，对象的数据以key-value的形式存在于数据库端。至于是谁弄进去的，就不得知了，可以认为是古人录入的数据。
其次，key-value的储存方式可以允许过期的数据存在，算作历史数据。
然后，每个key-value都有个编号，算是这个属性的版本号。读出时连同这个id号一起读出，写回时用这个id号检验时候可写入。这就解决了optimistic locking的问题。
再次，程序员决定要哪些对象的哪些属性，在内存里处理。
最后，同步的时候由程序员决定。为了不让自己的写入“过期”，他会安排尽快写回。

cray

2010-05-27 15:19

请问redorange是在回答我的问题吗?
首先, 你的设想跟EJB或者其他的框架处理optimistic locking没什么区别. 我的这个问题是基于你把所有对象都放在框架又不是即时同步的基础上的.

再次, 如果框架让程序员决定要哪些对象中的哪些属性, 那我觉得似乎不大合理, 一个project总不会由始至终由某些人做吧, 前人拿的属性, 后面开发或维护的人是不是会很不解呢? 还有, 比如我view显示多一列属性的话, 我需要修改多少个地方啊? 估计不是原来的人做的, 可能都不知道.

同步的时候由程序员决定, 我觉得每增加一个function, 我还要考虑这个, 这个框架只能说不好用. 而且数据之间的关系, 哪些数据是在同一个transaction里面的, 估计处理的时候很麻烦.

还有我很好奇对象不放内存, 会放哪里的问题? 期待解答.

BTW, 一个框架把东西都抛给程序员处理, 那也太不"负责任"了吧.

okhaoba

2010-05-28 14:11

2010年05月27日 10:29 "my3bit"的内容

感觉楼主是在说Hibernate ...

我也是这种感觉

sunson468

2010-05-28 21:48

hibernate其实就已经是这样的，诚然，方法与阁下所说的不太一样，毕竟数据库还是需要人为设定的～～

楼主的假设是基于对象，也就是说我们之需要关注现实业务对象，根本不需要关注数据对象，也不需要知道如何持久化对象，或者说不需要知道该怎么持久化对象，该持久化那些对象。

但我觉得这样的系统有些“浪费”，不可靠的，尽管他的好处是那么的诱人～
虽然我不是很深刻的理解领域对象，但我觉得任何对象都是有交互和交集的，完全独立的对象在数据世界里也许有，但是在现实社会是很难找到的～所以由现实对象自动转为数据对象是错综复杂而且重复的，除非我们的地球跟潘多拉星系一样，整个星球就是一个大的存储网络。
无论哪种策略，最后一层持久对象总是需要人为的设定的，即使key-value形式的对象数据库也是抽象于现实的一个独立模型，但这个领域对象是需要我们认为设定的，假设所有对象都按照所表现的形式保存起来，那么这个数据的容量或者性能是需要一定的硬件基础的

首先我觉得数据库还是得人为的设定，毕竟人可以区分的更精细，更具体，人可以根据实际的业务进行合理的划分和统筹，由人来划分数据对象，然后由ORM来自动管理对象，业务应用只需要针对我们认定的对象操作，那么这已经是比较合理的了，hibernate目前对对象的映射已经做到非常好了，尽管有些应用上性能还是个问题～

不区分或者配置一个区分规则，这些都得依赖于夸张的技术和硬件设备，我想你这个建议硬件产商会比较感兴趣，正如EJB哪种重量级的一样，全部自动化带来的后果就是人无法控制对象了。

YY一下：
一直以来都觉得我们把现实世界数字化是不是本身就是个错误。这样的仿生是不是错了～不过我也没别的方案。
人类的大脑到底是如何存储数据的呢？那么多的东西换成数据得需要多个TTTTTTB啊～～～而且大脑建立的索引是那么的可靠和高效，最夸张的是我们的大脑剁下来也不过几斤而已，体积总体而言也是非常的小。
人是如何区分保存对象的呢？

[该贴被sunson468于2010-05-28 21:55修改过]

[该贴被sunson468于2010-05-28 21:56修改过]

cuwkuhaihong

2010-05-29 00:34

我们在系统开发中经常使用这种带有监听缓存机制，在权限管理的是时候，经常要把常用角色对象放在内存中存储，用户使用时比较方便，不用再到数据库查找。而管理员修改角色信息就同步的缓存中去。

其实大家都在用，只不过没有归纳抽取出来而已。在编程界，只要理论性的通几乎就没有不可能实现的。

fireflyc

2010-05-29 02:51

其实有这种想法只能说明是在试图变成OO，已经意识到自己不是 OO了。
我们回忆自己的设计，先设计数据对把？这个就已经有问题来，以存储为中心设计出来的东西只能是一种事务脚本而不是一种OO的状态。你开始是数据库，那么之后你做的一切工作无非是在围绕在数据库，用合适的逻辑存放数据读取数据而已，而这个逻辑注定是一种事务脚本的风格。所以不难奇怪我们的代码中有那么多披着class皮的怪物来。

我觉得这个是思想的转变，必须是现有对象之后你再去考虑存储这个时候存储数据对你来说用什么存储基本上没有区别。但是这个转变很难，你能转变的回来别人不一定。所以我经常看到有些人为了所谓的性能往session里面放大量的数据。。一个系统到处是map。。再加上数据库。。。。。基本上是一种脚本的流程。

猜你喜欢

有2页 1 2 下一页