对象关系阻抗

命令查询职责分离模式Command Query Responsibility Segregation (CQRS)，也就是命令查询分离Command Query Separation [Young]有很多好处，

随着用户的爆发量增长，在某个凌晨醒来时，你发现：数据库已死。 数据库成已经为软件系统的主要性能瓶颈了 众多语言平台竞争中，为什么Java能够击败过去拳王数据库，夺得新的拳王冠军，以及他的特点所在。

Jease (Java with Ease) 是一个开源的内容管理框架，不是内容管理系统CMS，之所以称为框架，是因为它是完全OO面向对象，不依赖关系数据库，不是通常那种围绕关系数据库设计的CMS，这是其先进之处。 Jease引入了对象数据库，如 db4o

这是公司正接的一个小项目的一部分业务。要求是记录预约人请求在某个时间和某个会见人会见的预约。因为这个申请是面向网络，而且没有任何权限用户验证，谁都可以提交申请。所以每次都要记录新的预约人、会见人和预约时间等信息。也就是说三者是一对一的关系。如果维持一对多的关系，预约人和会见人信息有可能被随意提交的申

从“贫血”和“充血”说起 这两个词对我来说也是很新鲜的，看看我在Jdon的注册日期也就是从那时候开始才有所耳闻的。这两天看到有人在讨论于是整理了一下思维。 看到网络上很多的讨论中对于充血和贫血的看法往往是以绝对的

最近在做一个项目，有如下一个需求：用户可以加对方为好友。我采用hibernate映射，模型如下：public class Account{ private String id ; private String us

暴露领域模型（Exposed Domain Model）的不均匀性――一个问题引发的思考一个简单的问题 对象关系映射持久化引擎提供了弱类型的查询OQL，一个业务实体Person，现在要查找名字为**的人。模型层有两个可能做法：

小弟初到JDON，看了bang和道友的经典帖子感觉真的不错，看完后小弟有个疑问想请教各位：对于我们采用OO的设计理念进行的项目开发，对于采用DDD的设计方式，我们设计出的内容是完全不考虑数据库的，最后是在仓储中进行数据访问，那么疑惑出来了，对于以前说的表示层的VO和PO如果不匹配的话，或者一

在jdon潜水也有一段时日了，但还是有个问题困扰着，就是：我们都说在分析阶段要与数据库隔离，而围绕领域模型，但是系统的数据最终还是要保存在数据库中，如果用hibernate映射来实现，应该怎么做呢？如果根据模型来设计表的字段，是不是有可能会造成数据的冗余呢？能否用个具体的例子说明一下，不知我表达得清

抛弃了数据库，把对象加载到了缓存中，困难重重。 其中主要的一个问题是对缓存中的对象进行检索、筛选的问题。 以前这个问题是由数据库提供的SQL语言解决的，但是现在对象在缓存中，而检索缓存中的对象并没有一种类似于SQ

一、问题分析公司目前维护的一个系统，已经有超过8年的历史。现在遇到严重的性能问题，尤其是查询方面。系统简单介绍如下：1. 架构：客户端（windows程序）+服务端（J2EE,EJB,Web Service）+数据库（oracle）；2. 技术特点：客户端和服务端通过

Hi Banq, 看了很多JDON上的关于数据库已死的文章和讨论，我觉得在某些地方我还存在一些疑问，这些疑问应该是您提出的思维禁锢在以数据库为起点的范围内。我想弄清楚这些东西。 我本人是从数据库开始的，在03年-

我遇到一个问题，要动态生成一个小的xml文件，但是又不想让它存在硬盘上，因为只想用一下，就不需要了，有什么好的解决方法。

经常看到这方面的讨论，但还是不理解。大家讨论一下他们是怎么阻抗的，具体表现在哪里？

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

最近两年来，经常在OO和SQL这两兄弟阵营里转来转去，总想做出个“决断”，结果却是谁也舍不得，手心手背都是肉啊。 十年前学应用开发的时候，SQL是绝对的王者，一直也就用了好几年，搞定了不少事情。有时候也觉着烦，尤其是许多不相干的调用代码，罗罗嗦嗦粘贴个没完