关于设计模式与数据库,面向对象之间的关系 (200分)

  • 主题发起人 主题发起人 Beyondbill
  • 开始时间 开始时间
B

Beyondbill

Unregistered / Unconfirmed
GUEST, unregistred user!
在自已的开发过程中,常常发现一个很小的功能,但由于早期系统结构的不良性,总是要花费很大的维护代价才能实现.特别在数据库开发方面犹为如此.
一个良好的程序设计模式能给程序的可扩展性,通用性,可重用性等等很多方面带来好处.
设计模式是面向对象的产物,可是我在论谈上所看到的很多面向对象数据库程序充其量只是实现了界面与业务分离的功能,根本不具有通用性和扩展性等方面的功能,所以很想和大家讨论一下设计模式与数据库,面向对象三者的关系.以及怎样利用设计模式来进行良好的面向对象数据库程序的开发.
我相信这对于每一个搞数据库程序的人员来说都是一个挑战.
 
各位大富翁,怎么没有一点反应.是觉得大富翁上这样的问题太多,没有必要讨论吗?
可是你们查查大富翁论坛上的这方面的资料,充其量只是做到了企业规则与界面分离,还不算的上是面向对象的数据库.不具有可扩展性,通用性,可重用性.实现企业规则时特信赖于特定的数据集控件,没有把这些给分离出来.
 
你说的我很赞同,设计模式是软件工程中很核心也是很关键的一部分。但是要想真正理解与熟练的运用恐怕很少很少。设计模式给程序员带来的是编程的彻底的变化。
面向对象的数据库设计,如用powerdesign实现的可能是你说的企业规则与界面分离。
设计模式我现在充其量只能算是入门。实在是太高深的理论。建议你去csdn上去看看。上面的设计模式的文章较多。
 
这个问题比较宽.比较深.可以写一本书.
 
>>在自已的开发过程中,常常发现一个很小的功能,但由于早期系统结构的不良性,总是要花费很大的维护代价才能实现.
早期系统结构不良的原因,就是做的时候很满足于实现或是局限于实现,根本没有考虑或是很少考虑以后的维护。应了那句话,“人无远虑,必有近忧”。
想想看,你的早期结构是不是一个人想出来的,有没有拿出来大家研究一下,或是写成文档,做成成型的模型?
说多了无益,其实道理很简单。
 
我初学,这个方面的问题不参与意见,期待有较长工作经验的dfw解答
 
深有感觸。前期設計做不夠詳細,後面越難做。維護時更麻煩。
 
其实上面我说的把实现企业规则这部分但不信赖于特定的数据集或数据库操作,完全可以使用Bridge模式来实现,不知道各位还记不记得四大帮<设计模式>中第二章中的实现多操作系统窗体的实现就是使用Bridge模式来做到绘制窗体而不信赖于特定的操作系统函数调用.
 
大富翁高手都隐退了吗?看来只是我们这些小虾来这里灌灌水了.
 
很想和大家讨论一下关于面向数据库系统设计,可是,好像论坛上的人好像都没什么兴趣.可能是觉得我这样的小虾的题目还不够精典,简单了点吧.
反正我觉得像这样一个讨论对每一个设计数据库系统的人来说都是一个经常碰到,也很头痛,比较有挑战的问题.
 
失望....................................................
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?[?]
 
最近一直在研究设计模式,深深的感触到自己原来写的程序是如此的不堪一击,我认为要理解设计模式先要从设计原则上入手,那几条比较经典的原则在我们的日常开发中是经常能用到的,比如srp、ocp、替换原则等等,先把这些弄懂在来理解设计模式,并且还要结合自己做过的项目,这样才可以产生共鸣!-------我也是在学习ing,希望和大家共同讨论一下。
 
hb8069:
你好,很想跟你交流一下,你所说的比较经典的原则,比如srp、ocp、替换原则,我不太理解你这缩写的含义,不过,可能说出来大家都是想过或是做过的。我个人比较注重一种东东的设计,当然,也要有一定的技术支持。怎么样,十分的想请教你说的这几个原则,你在这里展开一下,大家讨论,或是,与我联系。
QQ989753。
 
还是在这里讲吧,相信想学习的人不至我一个.
 
你们说的都挺好 涉足D时间不长的我已经感觉到你所说的问题 那么设计模式是不是一个系统的总体设计呢,不完全是的
设计模式应具有通用性 可重用性 而且具有更高的扩展性
作这些工作应该是一个公司的系统分析员来做的 是一个公司的核心技术
 
TO Beyondbill:
首先,设计模式绝对不是面向对象的产物。它是候选的供他人重用的对已定义问题的成功解决方案。与OO没有关系。
其次,要做到数据库设计的拓展性可以从两方面下手:1、通盘考虑、分步实施,这是对任何设计都适用的方法;2、将DO(数据对象)与BO(业务对象)分离,它就是大家常说的三层架构的下两层。
 
谢谢大家的参与,我的设计思想与鲁棒的持久数据库设计类似,但还没考虑的那么全面.希望大家能继续讨论
 
模式就是一种定式,就象武功中的招式一样。四人帮的设计模式是讲的软件结构的东东,但是没有涉及到我们的业务模式,也没有涉及到数据库存储的模式。业务模式很多、很复杂,而且没有定论,只有靠自己的经验。关系数据库和对象很难有一个明确的对应。比如一个人对象,每个实例在内存中,人的属性和方法都是一个区域,而在数据库中,人在一个表中,属性在另一个表中,通过主键来联系。这两种存储方式导致了对象与数据库之间有了一个天然的鸿沟。对象存储方式便于我们专注于处理某个对象,而数据库存储方式便于我们批量查询。至于怎样实现两者的结合,是个很复杂的东东,绝不是几句话能说清楚的。但是有一点很清楚,每个类应该高内聚,输出方法尽可能少。
 
我也很有兴趣学习一下!
 
高手的地方!
 
后退
顶部