数据库操作与面向对象程序设计的矛盾

Question

各位兄台，小弟如今写程序遇到设计上的问题，想请教：
1.如果采用直接操作数据库那么面向对象的设计方法用不上(我觉得面向对象设计方法很好)
2.如果采用面向对象的设计方法，那么对象的属性数据赋值过于麻烦.......
如何设计比较好？

Answer 1

使用ADO时：command，record，table其实也是面向对象的概念。不要在界面上操作上直接用SQL语句，不然的话以后修改就很麻烦了。

Answer 2

请看《企业应用架构模式》
（《Patterns of Enterprise Application Architecture》）
Martin Flower著
简述如下：业务逻辑采用TableModel
DataSoure的入口用TableDataGateway或RowDataGateway,
以下又DataMapper,DataHolder等可选部件
其实很复杂，详述见书。成型的模型有MVP(Delphi版实现 By Joanna),该模型很复杂，完全不用数据感知控件，适合大型系统使用。
简单点的Philip Brown的一个模型，小巧，很实用。

Answer 3

需要Philip Brown和MVP(Delphi版实现 By Joanna）的请发邮件到[email protected],
我27号晚上发给大家。

Answer 4

没有问题的。
看看.net的framework  adi*dadi
能够结合的很好

Answer 5

矛盾确实有的，steelhorse(铁马) 说的那些资料我没有看过，但想来是非常不错的。
软件以用为本，相对于需求与实现这对矛盾，它俩的矛盾就次要得多了。。

Answer 6

MVP和Philip Brown的模型已经发出，请仔细阅读里面的word文档，
不要急于全部弄懂，把计划订在三个月以上。（我看了9个月并且没有完全精通）MVP本身不能处理与数据库连接。
和MVP相关的还有OPF,请在google上搜索OPF察看详细内容。
这些模型是与语言无关的，但在Delphi中肯定能实现。搂主的问题实际上是如何实现实体层的问题，
以下文章对实体层的类和之间的关系作了探讨
http://objects.nease.net/persistenceLayer_ch.pdf欢迎交流！

Answer 7

谢谢大家，这几天公司挺忙得，没有回复。
我现在用Delphi，如果把各种对象设计出来问题不大（比如功能对象、数据对象、实体对象），可是在使用分布式开发过程中实际应用感觉力不从心，对很多面向对象的设计方法能够比较好的理解，但是应用的时候.........
个人认为不要直接操作数据，采用面向对象设计方法比较好
希望大家讨论、指点
steelhorse(铁马)谢谢我已经发了邮件不过迟到了 :)

Answer 8

给  halfdream(哈欠) 
你说的对，但是好的设计方法可以便于开发和维护，软件本身能够更加健壮，对用户来讲如果需求变化，这边也能够应付，不知道这样说对不对

Answer 9

>>采用面向对象设计方法比较好。。这个比较好的评价标准是什么呢?
呵,这是个值得深入思考的问题..
当你能向你老师,老板,同事,项目组成员,用户,客户等不同人证明出这个'好'在哪儿,
这是算真正明白它的好..
有的因素,往往被忽视,就是工具...这个工具指的包括开发语言,IDE,支持平台,其它一系列
工具.....当你同时对一类架构模型使用EJB和COM+或DCOM实现过,你会深深感觉因工具不同而造成的
差异...甚至有些算起来很小的差别,使用DCOM的时候,用不用MIDAS数据打包技术,这也会造
成设计和实现上的差别.
这些差异是客户存在,必须正视的.

Answer 10

晕..敲错了....这些差异是客观存在的.必须正视的...数据库模型主要也就是实体与关系模型,与对象模型存在着对应关系和矛盾.
以对象模型为中心的开发一般来说,要比数据库为中心的开发付出更多,
但这些代价在相当情况下是值得的,简单说,对象模型中心开发的好处是
设计模型与具体实现能够相当一致...这对较复杂的系统是相当有价值的.
很多开发工具,类库等,都给出了多种解决方法.
就象铁马上面给出的那些资料那样...
与DELPHI比较起来,JAVA在这些方面就走得比较前面...也许同市场定位关系吧

Answer 11

铁马发的邮件已经收到,先鸣谢一下.
正在学习中.
确实,在这一方面,基于Java的实现方案较多,使用Delphi的就......