HOT! 面向对象、设计模式入门 （1号帖） 再学 面向对象 在 数据库程序开发中的具体应用！ 一个多年使用Delphi开发的OO新手的困惑！ ( 积分: 50

  • 主题发起人 主题发起人 Smile.java
  • 开始时间 开始时间
S

Smile.java

Unregistered / Unconfirmed
GUEST, unregistred user!
HOT! 面向对象、设计模式入门 （1号帖） 再学 面向对象 在 数据库程序开发中的具体应用！ 一个多年使用Delphi开发的OO新手的困惑！ ( 积分: 50 )<br />曾几何时，Delphi成为我生活的一部分。怀着几分偏爱，随着亲爱的Delphi女神，
写出了一个又一个数据库程序，一个又一个MIS在客户那里使用。
然而，用着这么好的纯OO的RAD，却整天写着非面向对象的代码，在做同一行业的MIS时，
发现自己代码的重用竟然是个梦，我多年挂在嘴上的OO、面向对象如何在数据库开发中
实现呢？
最近在写万行左右的三层小MIS程序，朋友劝我不要考虑面向对象了，他说有这样的说法，
小程序根本不用面向对象，几十万的中型软件需要面向对象了，几百万的大系统没有面向
对象就根本不行了。我的程序只有万行代码，我追求面向对象错了吗？难道仅仅是为了学
习也不值得多此一举吗？
具体如何做呢？程序中的数据集全转成对象吗？
比如小型系统中只把业务对象封装起来还是把业务逻辑也抽象成类？
看了几位朋友的帖子，感觉自己有点过于执着于OO，呵呵，能给点具体的建议吗？
TO:defcjjava 以下不太明白什么意思：）
“事务脚本的架构，通过一个简单的数据库封装器来操作一系列的事务。”
 
曾几何时，Delphi成为我生活的一部分。怀着几分偏爱，随着亲爱的Delphi女神，
写出了一个又一个数据库程序，一个又一个MIS在客户那里使用。
然而，用着这么好的纯OO的RAD，却整天写着非面向对象的代码，在做同一行业的MIS时，
发现自己代码的重用竟然是个梦，我多年挂在嘴上的OO、面向对象如何在数据库开发中
实现呢？
最近在写万行左右的三层小MIS程序，朋友劝我不要考虑面向对象了，他说有这样的说法，
小程序根本不用面向对象，几十万的中型软件需要面向对象了，几百万的大系统没有面向
对象就根本不行了。我的程序只有万行代码，我追求面向对象错了吗？难道仅仅是为了学
习也不值得多此一举吗？
具体如何做呢？程序中的数据集全转成对象吗？
比如小型系统中只把业务对象封装起来还是把业务逻辑也抽象成类？
看了几位朋友的帖子，感觉自己有点过于执着于OO，呵呵，能给点具体的建议吗？
TO:defcjjava 以下不太明白什么意思：）
“事务脚本的架构，通过一个简单的数据库封装器来操作一系列的事务。”
 
有同样的感觉，郁闷中.............，数据集全转成对象可不那么简单
 
如果数据集不全转成对象是不是就不完全是面向对象编程了？
是否只是在必要的时候才需要设计相应的类？
另外，三层结构如何具体实现面向对象呢？ 比如一般的收费系统（比较常见的系统），
如何在Delphi中规划类和接口呢？
用户信息定义一个类
收费信息定义一个类
操作员及权限定义一个类
……
如果数据库结构发生一点变化，岂不是相应的类都要修改？
 
首先面向对象的设计并不是要强加于一个系统之上的，中小型的系统我看还没有必要全部采用面向对象的设计，可以部分的采用面向对象
但是遇到大型的系统时，往往业务会很复杂，变化会很频繁，这就需要面向对象的设计，这是一个自然的事。
Delphi中的接口比较难于理解，可以看看Java或是C＃的实现，原理基本是一样的，另外要多用用ModalMake进行建模。
 
我的一点理解,不一定对,请大家批判指教:
数据库开发最常用的对象是什么?
不是一个个具体的表,而是编辑器对象(用于数据录入,查询),报表对象(用于报表输出),用户对象(用于用户权限控制),action,菜单对象(用于系统控制)等等,这些是系统的框架对象,这些重用率很高,应优先考虑
那么具体一个个表的对象干吗用呢,用于保存业务规则.
至于是否要把表完全映射到对象(到记录级),我认为意思不大,一则这样作你就必须重新构造一套表操作的对象,效率和可靠性都不高,二则就无法利用DELPHI大量的第三方控件,也就失去了DELPHI的最大的优势之一.
 
我认为关键是设计业务的OO,也就是表设计的OO,至于数据到程序中的对象映射含义不大,即使是大型系统也没什么含义,除非数据的存储是用的对象数据库
 
我个人感觉，对小系统的确没有必要完全面向对象。就像Martin在POEAA中讲的业务不复杂的系统，可以采用事务脚本的架构，通过一个简单的数据库封装器来操作一系列的事务。尽量把变化的SQL语句封装在一个小区域里，使需求的变化不产生较大的变化。但变化是不可避免的。
 
在数据库领域，SQL远比OO成功。SQL的S是什么意思？STRUCTURE
OO在数据库领域目前的流行概念是持久层，但似乎成功的系统也不是很多。
 
我也觉得把数据表抽象成类的必要性不是很大，但在其它的一些方面，用类确实很方便，很好用。
 
OO并非这个世界的全部。我们做工程的人，因为做出来的东西是要实际使用的，我们
开发的周期是公司经营的重要组成部分，不能象某些书商一样，外面有什么需求，或者
根本就是自己制造噱头，来写书或出版书-----更恐怖的是自己本来就是一知半解。用一位总工的话说，都是 t.m.d这些书商把事情弄的越来越复杂。
OO并不神秘，也不是世界的全部，听听soul 与 aimingoo的讨论：
http://www.01cn.net/cgi-bin/topic_show.cgi?id=543&amp;h=1&amp;bpg=1&amp;age=0
 
再来一篇：
http://www.01cn.net/cgi-bin/topic_show.cgi?id=1734&amp;h=1#8309
 
非常同意楼主朋友的看法
 
TO:楼主：&quot;事务脚本的架构，通过一个简单的数据库封装器来操作一系列的事务。”我指的是比较简单的数据库操作，比如说增删查改，用一个DataAccessObj封装起来，这样避免了一些重复代码，从而在一定程度上封装了变化。不对之处，请指教。
 
>>不是一个个具体的表,而是编辑器对象(用于数据录入,查询),报表对象(用于报表输出),用户对象(用于用户权限控制),action,菜单对象(用于系统控制)等等,这些是系统的框架对象,这些重用率很高,应优先考虑
那么具体一个个表的对象干吗用呢,用于保存业务规则.
至于是否要把表完全映射到对象(到记录级),我认为意思不大,一则这样作你就必须重新构造一套表操作的对象,效率和可靠性都不高,二则就无法利用DELPHI大量的第三方控件,也就失去了DELPHI的最大的优势之一.
严重同意[:D]
 
个人觉得如果现在的ORMapping技术成熟的话，考虑将表映射成实体类，然后增加相应的方法。
但这种实体类大多是简单对数据库中的表进行封装，在具体编程中，很少用于继承，这样对代码重用感觉贡献不大。类的继承功能相当于废弃不用了，或者说没有发挥应该的作用。
所以觉得还是写一些通用的数据库类能好些，比较具有实际意义。
 
通过对OO的局部应用，我的做法是首先建立一个可以继承的共用数据库的类，然后再在此类的基础上根据表的字段建立第一层实体类（这个类可以由代码生成器生成，生成的速度极快，也不会出错），再在第一层实体的基础上通过继承建立第二层实体类，第二层实体包含了此类所有的属性和方法。
如果一个方法需要调用两个表以上的数据或者方法，我觉得是最难处理的，只好再建立一个超级类，将所有的表第二层实体类包含在此超级类中（目前我还没有使用接口）。
我这样使用OO的方法的优点是：一、可以使用数据敏感控件，也可以不使用；二、可以由代码生成器生成大部分代码；三、由超级类来管理所有的实体类，以实现类之间的通讯和共享；四、可以实现功能类和界面的很好分离。缺点：一、还没有使用接口；二、实体类之间的联系做得还不是很好；三、还没有充分应用模式设计；四、实体类和数据敏感控件的绑定不能够采用拖放绑定，只能够采用代码进行动态绑定。
 
我还说一点，千万不要做成一记录一对象，这样做简直是对delphi资源的浪费（不过，特殊情况除外）
 
下载：
关于最后一滴血，请到云南信息港http://it.yninfo.com/soft/download/soft/35/102/44.shtml
或者ftp://220.165.4.105/soft/down/2005-3-10/Ver3.3.rar
曾经的论坛:http://www.delphibbs.com/delphibbs/dispq.asp?lid=3005644
--------------- 里面就有自动生成delphi 类的活色生香的例子!
 
我在数据库程序时，就是用数据集，再把数据集转换成对象有什么好处，没有发现，只是觉得又多了一个转换而已
 
您必须登录或注册才可回复。

Similar threads

Ray
[转]终于可以发布Delphi下收点OSGI精髓皮毛而设计的插件框架WisdomPluginFramework
回复
4
查看
4K
chlkuei
C
老
关于面向对象的困惑及其他。(200分)
回复
7
查看
210
creation-zy
C
B
dephi适合面向对象的开发吗？我有点怀疑！(0分)
2
回复
39
查看
498
QSmile
Q
F
该用何对象(200分)
回复
6
查看
210
first
F
东
Com对象创建时不调用构造函数？(关于Com环境下的OO设计)(200分)
回复
10
查看
124
东张西望
东
后退
顶部