|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
最后更新时间:2007-12-07
diystyle 写道 看来我们大火仍然对DDD有种偏见啊。DDD严格意义来讲和具体的编程中实用的技术设置编程语言是没有必然的联系。感觉DDD是我们去分析和理解我们软件要实现最终目标或者功能的一种方式,它所得到的只是一个一个所要解决问题的一个抽象的东西。而要实现这个抽像的东西才是具体的编程技术来讨论的事情了。也不知道这种理解是否正确?呵呵 是一种工作方式(对于我们的项目来说)
每个领域都有不同的工作方式 比较常见的, 审批流(又叫作工作流?发明这词的人应该是个翻译) 物流系统, 资源管理系统(ERP 包括NN种东西。。。没哪家作的看的上眼) 财务管理系统(ERP一部分) BBS(这个也算是。。。。一种领域) |
|
| 返回顶楼 | |
|
最后更新时间:2007-12-07
呵呵,难道设计时要同时兼顾域模型和关系数据库模型吗?貌似现在Evans DDD的争议很多,好像都波及到Hibernate这个框架的争议了
|
|
| 返回顶楼 | |
|
最后更新时间:2007-12-07
异常兄批评的很对,疏忽了,平时自己写英文简写写惯了。。
RDB——关系数据库 00DB——面向对象的数据库 |
|
| 返回顶楼 | |
|
最后更新时间:2007-12-11
我只是想知道使用Hibernate时,采用哪种模型驱动比较好
|
|
| 返回顶楼 | |
|
最后更新时间:2007-12-11
两个不在同一个层次上。。。。
就如同别人说打地基时用的黄色的大理石。。。 可以让建筑物更高贵一样。。。(跟本没人看的见。。。。) PS:OO不是目的,目的是把不好理解,容易出问题的部分封装。 领域不是目的,目的是更好的抽象业务。 |
|
| 返回顶楼 | |
|
最后更新时间:2007-12-12
赐教了 异常兄不妨介绍下关于持久层方面的一些设计经验
|
|
| 返回顶楼 | |
|
最后更新时间:2007-12-12
1.领域常用的是充血模型。
2.把一个表的内容尽量的减少。 3.由2之后把常用的统计查询用视图来表现 (如果业务充许的话还可以用影射视图缓存) |
|
| 返回顶楼 | |
|
最后更新时间:2007-12-13
不太理解异常兄的意思
下面一个基于B/S的学生在线评价教师的系统 evaluate_detalis表格是评价指标 1、evaluate_process表格是学生首先从界面里面选择所在班级的任课教师和相应的课程的每一个指标对其进行评价(选择评价等级 优良中差) 2、evaluate_result表格存放的信息是 当学生评价完毕时管理员对该老师的课程进行结束评价的操作,系统自动计算出每一个评价指标的加权评价等级并将结果写到这个表格里面 以下是这个系统可能的关系。。 针对这样的系统 如果使用Hibernate设计持久层 遵循怎样的设计流程最好呢 |
|
| 返回顶楼 | |
|
最后更新时间:2007-12-13
同学,表的设计不错!
|
|
| 返回顶楼 | |
|
最后更新时间:2007-12-14
通常决定是否基于数据库设计和基于领域模型设计取决于你的分析结果——分析模型。
众所周知:数据库设计基于两种设计粒度:表和字段; 如果分析模型和数据库存在如下差异,则应当考虑采用领域模型: 1. 表粒度所能提供的结构化能力无法支持分析模型,比如一个分析模型的数据是分布在多张表中,或者一张表中表示的分析模型有多种(即ORM所支持的几种继承能力,以及component) 2. 字段粒度所能提供逻辑无法支持分析模型,存在较多逻辑计算依赖多个字段甚至是不定字段。 如果以上两种情况都满足,那么采用领域模型设计,无疑拥有较好的设计开发成本,同时设计和分析的差异性在较小范围内,沟通成本也将保持较低的范围内 |
|
| 返回顶楼 | |







