- 浏览: 39394 次
- 性别:
文章分类
最新评论
-
sunheavenvan:
我觉得不存在提炼出有所谓的本质,提炼的目的是获取较为准确的心智 ...
Jdon007四象图坐标表示 -
yangyi:
好像没有提及Seam给测试和OO设计上带来的便宜,不好意思,还 ...
Seam生命周期 -
buptwhisper:
性能一直是个问题
Seam生命周期 -
sulong:
oojdon 写道如果大家站在Gavin King的角度,包括 ...
Seam生命周期 -
may_cauc:
扬长避短吧,任何一种技术的出现都有其初衷。不要轻易否定,在否定 ...
Seam生命周期
这是DDD的原文,我认为最好的结论就是最后加粗部分,让模型和数据分开,而不是折中处理,这也是CQRS的本质。Designing Objects for Relational DatabasesThe most common nonobject component of primarily object-oriented software systems is the relational database. This reality presents the usual problems of a mixture of paradigms (see Chapter 5). But the database is more intimately related to the object model than are most other components. The database is not just interacting with the objects; it is storing the persistent form of the data that makes up the objects themselves. A good deal has been written about the technical challenges of mapping objects to relational tables and effectively storing and retrieving them. A recent discussion can be found in Fowler 2002. There are reasonably refined tools for creating and managing mappings between the two. Apart from the technical concerns, this mismatch can have a significant impact on the object model. There are three common cases:
When the database schema is being created specifically as a store for the objects, it is worth accepting some model limitations in order to keep the mapping very simple. Without other demands on schema design, the database can be structured to make aggregate integrity safer and more efficient as updates are made. Technically, the relational table design does not have to reflect the domain model. Mapping tools are sophisticated enough to bridge significant differences. The trouble is, multiple overlapping models are just too complicated. Many of the same arguments presented for MODEL-DRIVEN DESIGN—avoiding separate analysis and design models—apply to this mismatch. This does entail some sacrifice in the richness of the object model, and sometimes compromises have to be made in the database design (such as selective denormalization), but to do otherwise is to risk losing the tight coupling of model and implementation. This approach doesn't require a simplistic one-object/one-table mapping. Depending on the power of the mapping tool, some aggregation or composition of objects may be possible. But it is crucial that the mappings be transparent, easily understandable by inspecting the code or reading entries in the mapping tool.
On the other hand, there are many cases in which the data comes from a legacy or external system that was never intended as a store of objects. In this situation, there are, in reality, two domain models coexisting in the same system. Chapter 14, "Maintaining Model Integrity," deals with this issue in depth. It may make sense to conform to the model implicit in the other system, or it may be better to make the model completely distinct. Another reason for exceptions is performance. Quirky design changes may have to be introduced to solve execution speed problems.
But for the important common case of a relational database acting as the persistent form of an object-oriented domain, simple directness is best. A table row should contain an object, perhaps along with subsidiaries in an AGGREGATE. A foreign key in the table should translate to a reference to another ENTITY object. The necessity of sometimes deviating from this simple directness should not lead to total abandonment of the principle of simple mappings.
The UBIQUITOUS LANGUAGE can help tie the object and relational components together to a single model. The names and associations of elements in the objects should correspond meticulously to those of the relational tables. Although the power of some mapping tools may make this seem unnecessary, subtle differences in relationships will cause a lot of confusion.
The tradition of refactoring that has increasingly taken hold in the object world has not really affected relational database design much. What's more, serious data migration issues discourage frequent change. This may create a drag on the refactoring of the object model, but if the object model and the database model start to diverge, transparency can be lost quickly.
Finally, there are some reasons to go with a schema that is quite distinct from the object model, even when the database is being created specifically for your system. The database may also be used by other software that will not instantiate objects. The database may require little change, even while the behavior of the objects changes or evolves rapidly. Cutting the two loose from each other is a seductive path. It is often taken unintentionally, when the team fails to keep the database current with the model. If the separation is chosen consciously, it can result in a clean database schema—not an awkward one full of compromises conforming to last year's object model. |
发表评论
-
论继承
2011-09-05 17:37 218继承是现实系统中非常 ... -
Jdon007四象图坐标表示
2011-09-03 11:42 1561http://www.jdon.com/jivejdon/th ... -
面向对象掠影
2011-07-16 22:25 796转自链接:http://www.cnblo ... -
specification 规格模式
2011-02-14 22:57 115MF 和 Evans 发明的模式 -
A comparison of DCI and SOA, in Java_003
2011-02-14 12:43 62DCI和SOA的对照 -
DCI architecture - The Common Sense of Object Orientated Programming
2011-02-14 12:38 77In regular OO, I work with cla ... -
MVC To DCI
2011-02-14 12:29 204MVC to DCI -
DCI in Real World
2011-02-14 12:22 796逃出面向类编程的魔爪,重新思考对象 This is a ... -
DCI之转账简单Example
2011-02-14 11:33 194http://stackoverflow.com/questi ... -
The DCI Architecture
2011-02-14 01:05 1126The DCI Architecture: A ... -
DDD 概念
2011-02-11 15:22 738来自一个PPT的截图 ... -
UML元素
2011-02-11 14:52 626UML 统一建模语言,它是表达我们OO建模的图形工具,UML图 ... -
Rethinking architecture with CQRS
2011-02-10 22:57 878这是axonframework的作者Allard Buijze ... -
DCI and Services (EJB)
2011-02-10 22:38 736http://blog.maxant.co.uk/peb ... -
来自Jdon的DDD总结
2011-02-10 22:31 896http://www.jdon.com/jivejdon/th ... -
DDD设计,为什么我热爱CQRS
2011-02-10 22:25 1462地址是:http://jonathan-oliver.bl ... -
设计模式的脉络
2011-02-10 14:13 693设计模式一般是指GOF那本书引出来的名词,其应该是代码模式,而 ... -
对象设计原则
2011-02-08 00:36 685现在我们面对的是让人 ...
相关推荐
面向对象的关系数据库设计 面向对象的关系数据库设计
我们将对象数据库管理系统定义为一个...ODBMS这所以与关系数据库不同,是因为 ODBMS存储的是对象,而不是表格。对象的引用通过持久性标识进行,PID可以独一无二地识别各个对象,可以用来在对象之间建立标记和容器关系。
针对面向对象技术和关系数据库的特点,将两者相结合,建立了对象关系数据库管理系统,既支持已经被广泛使用的SQL,不仅...文中还提出了对象关系数据库的设计方法和对象映射成关系数据库的方式,其方式简便,实用性强。
基于对象关系数据库设计了一个移动对象的数据模型,查询语言和相应的数据库管理系统。此系统结合GIS数据库系统能够表述移动物体和支持对运动物体的查询,从而实现基于位置的服务。本系统支持不确定性和复杂可扩展的...
数据库设计,讲解业务实体对象到数据库表的映射关系。
一个关系数据库系统可以支持几种语言和多种终端使用方式 ,但必须至少有一种语言,它的语句能够一某种定义良好的语法表示为字符串, 并能全面地支持以下所有规则:数据定义、视图定义、数据操作、约束、授权以 及...
日 期: 批 准: 日 期: ********* 版权所有 不得复制 时代集团产品跟踪平台 1 数据库设计说明书 1 1 引言 2 1.1 编写目的 2 1.2 术语表 2 1.3 参考资料 3 2 数据库环境说明 3 数据库设计模板全文共27页,当前为第...
数据库设计教案全文共2页,当前为第1页。数据库设计教案全文共2页,当前为第1页。数据库设计 数据库设计教案全文共2页,当前为第1页。 数据库设计教案全文共2页,当前为第1页。 成功的数据库设计是应用系统开发的...
为了支持相关程序运行,数据库设计就变得异常复杂,因此最佳设计不可能一蹴而就,而只能是一种“反复探寻,逐步求精”的过程,也就是规划和结构化数据库中的数据对象以及这些数据对象之间关系的过程
2. 面向对象分析和设计 () 2.1. 用例分析 () 2.2. 类和对象设计 () 3. 逻辑结构设计 () 3.1. 类和对象向关系模式转换 () 3.2. 关系模式优化 () 4. 数据库物理结构设计 () 4.1. 存取方法设计 () 4.2. 存储结构设计 ()...
逻辑阶段可采用的有效方法 ODL(Object Definition Language)方法 面向对象的数据库设计方法 计算机辅助设计 ORACLE Designer 2000 SYBASE PowerDesigner 数据库设计培训全文共37页,当前为第6页。 数据库设计概述 ...
关系数据库设计(总8页) 目录 一 Codd的RDBMS12法则——RDBMS的起源 二 关系型数据库设计阶段 三 设计原则 四 命名规则 数据库设计,一个软件项目成功的基石。很多从业人员都认为,数据库设计其实不 那么重要。现实中...
统一的数据子语言法则 一个关系数据库系统可以支持几种语言和多种终端使用方式,但 必须至少有一种语言,它的语句能够一某种定义良好的语法表示为字符串,并能全面地 支持以下所有规则:数据定义、视图定义、数据...
一个关系数据库系统可以支持几种语言和多种终端使用方式 ,但必须至少有一种语言,它的语句能够一某种定义良好的语法表示为字符串, 并能全面地支持以下所有规则:数据定义、视图定义、数据操作、约束、授权以 及...
表、视图、字段、数据类型、长度、主键、外 键、索引、是否为空、默认值、 概念模型到物理模型的转换:把概念模型中的对象转换成物理模型的对象。 5. 对象的转换: "对象 "概念模型 "逻辑模型 "物理模型 " "实体 ...
设计数据库关系模型 数据库设计就是将数据库中的数据对象以及这些数据对象之间关系进行规划和结构化的过程 为什么需要设计数据库 修建茅屋需要设计吗? 修建大厦需要设计吗? 结论:当数据库比较复杂时我们需要设计...
1.3 设计阶段 设计阶段可以说是以后系统性能的关键阶段, 在这个阶段, 有一个关系到以后几乎所有性能调优的过程—数据库设计。 在数据库设计完成后,可以进行初步的索引设计,好的索引设计可以指导编码阶段写出高...
为了支持相关程序运行,数据库设计就变得异常复杂,因此最佳设计不可能一蹴而就,而只能是一种"反复探寻,逐步求精"的过程,也就是规划和结构化数据库中的数据对象以及这些数据对象之间关系的过程。 数据库设计的...
基于Oracle9i中面向对象关系数据库程序设计.pdf