在自已的开发过程中,常常发现一个很小的功能,但由于早期系统结构的不良性,总是要花费很大的维护代价才能实现.特别在数据库开发方面犹为如此.
一个良好的程序设计模式能给程序的可扩展性,通用性,可重用性等等很多方面带来好处.
设计模式是面向对象的产物,可是我在论谈上所看到的很多面向对象数据库程序充其量只是实现了界面与业务分离的功能,根本不具有通用性和扩展性等方面的功能,所以很想和大家讨论一下设计模式与数据库,面向对象三者的关系.以及怎样利用设计模式来进行良好的面向对象数据库程序的开发.
我相信这对于每一个搞数据库程序的人员来说都是一个挑战.
一个良好的程序设计模式能给程序的可扩展性,通用性,可重用性等等很多方面带来好处.
设计模式是面向对象的产物,可是我在论谈上所看到的很多面向对象数据库程序充其量只是实现了界面与业务分离的功能,根本不具有通用性和扩展性等方面的功能,所以很想和大家讨论一下设计模式与数据库,面向对象三者的关系.以及怎样利用设计模式来进行良好的面向对象数据库程序的开发.
我相信这对于每一个搞数据库程序的人员来说都是一个挑战.
我想你可能还没明白我的意思,我指的是用面向对象的思想去开发数据库程序,并不是指面向对象数据库.
希望大家能讨论一下.
按照Matin Folwer 的思想是使用Table Module模式来解决,可是很多开发人员写出来的虽然按照了这种模式,却把操作的数据数据集给限定死了,实现企业规则时就信赖于特定的数据集控件,比如TADOQuery或TDataset.还有,如果系统再增加或修改一些功能时,可能又要做比较大的修改.
我希望能和大家讨论的就是怎么实现上述这样的通用性,可扩展性,可重用性这样一些功能.
用OO设计DB其实没有什么意义，首先OO思想和RELATIONAL是不太兼容的思想，如果一定要OO，用ORM才是好办法
关于你的:使用存储过程的优点是性能较好，但代价是失去移植性 这个问题只要使用中介对象就可以解决了.把它分离出去.像我说的使用Bridge就是这么一回事,对于特定的数据库或数据集操作通过Bridge分离出去以后,在主控模块通过调用不同的实现来完成一样的功能.
。（用OO设计DB其实没有什么意义，首先OO思想和RELATIONAL是不太兼容的思想，如果一定要OO，用ORM才是好办法）我最近也常想这个问题，感觉在做数据库应用程序的时候实在面向表，或者是面向用户界面。很少考虑到面向对象。网上也看过一个文章，写的是关于对象的封装，作者希望能够把很小的东西（可以说是一个字段）封装成对象，这样来实现其可重用性，但是好像在现实中很难操作（我觉得这样工程太大，费用太高，不适合中国国情）。在学java时，ejb中把数据库的内容又在程序中重新封装，改造成对象。这样，程序只负责这些对象的维护，可以让ejb容器进行数据库的维护（也可以自己进行数据库的维护），不知道这样是不是很好地解决方案。没有实际的经验，看上去很美。关于模式没有怎么学过。不敢乱说。
Bridge也只能是在中间层实现，不可能在RDBMS中实现，虽然它可以隔离BO和DB，但是进行数据库移植时仍然面临着需要重写SP的问题，我所说的“失去移植性”不是说不能移植，但是代价较高。TO：idilent(忍不住来讨论)
过奖了，其实偶的看法都素在CSDN上讨论出来滴:)
对于你说的过度OO，偶认为是不妥的，OO的目的是为了简化开发，过小的对象粒度必然导致对象间关系（接口）的复杂化，得不偿失。
在我心中构造的一个比较完美的数据库系统应该是按照Table Module来实现企业规则与界面分离,而这个实现企业规则的类则使用Bridge模式调用一个实现企业规则的抽象实例创建真正的实现企业规则的对象来实现.
具体层次关系你可以参考一下四大帮的<设计模式>中的第二章.我想你应该看过的.
该文给出一个业务层/数据层分离概要设计，
可以很好的解决楼主的问题。
如需要请email至[email protected]
多谢,你这篇文章我看了,很不错,但实际中自己开发一个这样的persistentLayer是不现实的,最好还是考虑现成的,如BORLAND在D7中提供的BOLDTO:AWolfBoy(龍行江湖)
你赞成你的观点，但是我前面是针对SP而言的，你说的这些都是中间层的东东。对于数据库这边的设计，还是要看整个系统的结构，如果是两层应用，当然还是传统的ERD+VIEW+SP+TRIGGER那一套，如果是三层就有多种实现方式了，你说的是一个方面，除了业务逻辑和界面分离外，牛仔所说的业务逻辑与数据持久之间的分离也是一个方面。
而数据持久这一方面至少有两种，现在用得最多的还是沿用ERD那一套，但对于复杂应用等方面就有困难，所以又有了ORM，个人认为ORM在未来还是很有前途的。当使用ORM（如BORLAND的ECO）的话，DB设计就已经不是很重要了，只要BO这边设计好，DB Schema就自动生成了。
来实际开发一个零售行业的进销存软件。 当然如果按该文中所述的对象来设计的话是有一点难度，考虑到
Delphi三层的特点对这个设计进行了一些修改，要做到业务层和
数据层的分离还是可行的。 在我开发的这个进销存软件中，做到了用户界面/业务层/数据层
的完全分离！ 晚些我会开个贴并发布一个大致的框架，希望大家能指正。
自我感觉，在以后扩充的过程中，可以直接扩充这个类，界面调用的时候，也只是增加处理一下这个类的新属性或者方法就可以了。总体来说，扩展的代价是不高的。除非数据库设计有比较大的改动。
Stored procedures
Normally we would recommend to customers that they use stored procedures to access tables in the database. There are several reasons for this: Stored procedures provide a clean mechanism to encapsulate queries.
Changing a query can be done without changing the data access code.
A DBA can easily see what SQL statements are being executed.
Stored procedures are typically more secure, and it is easier to control database access.
By using stored procedures you can avoid round trips to the client by issuing more than one request in the stored procedure.
Stored procedures usually offer the best performance compared to middle-tier-generated SQL.
Stored procedures offer an excellent way to encapsulate XML queries and XML input parameters.
The disadvantage of stored procedures is they tend to be proprietary and are not portable across platforms. 最近也看MS Petshop的代码，（什么语言无所谓，思想真的不错）
Data Access Layer
DAL完成数据库访问任务，上层(BLL：用户（business Logic Layer）)直需调用接口即可，不用知道具体访问细节，也不用知道有什么样的数据库和数据库表等信息
接口中定义了要用的方法，当调用接口时会根据具体的情况再去调用底层数据访问操作。而现在这个DALFactory就是关键，当BLL层要操作数据库时，DALFactory会根据具体情况再去使用本文上面介绍的SqlServerDAL和OracleDAL中的一个。这样系统上层只管调用，而下层来实现细节，上级只管发号施令，下级去干活。对于上层来说实现细节被隐藏了
預想一個設計：
有以下對象：
1、用戶 ：這是需求的來源。
2、數據存貯者：負責存貯層，用戶不必知道數據是放在哪裡。MIDAS是一個特例。但要應用MIDAS還是複雜些，簡單的數據存貯者可只為用戶指明存放地點(即數據庫連接)
3、數據控制者：給出用戶可以操作的數據子集，可以用這個來實現數據流
4、界面顯示者: 就是各種Form的調度了。
5、其他系統服務者: 定時服務，數據分發服務，
操作關系:用戶向數據控制者要SQL語句 ,然後向數據存貯者取回數據集,最後交給界面顯示者顯示出界面.(注：這些屬於系統框架設計，不屬於問題領域的對象設計)
通過這個調度過程，數據庫與需求是隔開的，不過這只是系統系統對象的隔離而已，我們所關心的用戶的數據，不管中間經過什麼隔離，其最終：因為我們把數據用實體關系模型化(也就是存入關系型數據庫中)。
舉個例子說明一下，例如：企業資源中，主要的幾種資源：人力，資金，資產，物料，客戶,產品，加工工藝... 主要的資源分配過程：MRP過程，生產過程，... 控制資源分配的過程：工作流程控制，數據流向控制....
那麼在我們面對的這些問題領域(需求的解決上)，在面對這些對象時，我們怎樣用面向對象的方法去解決我們所面對的問題對象，而且還要將數據保存在關系型數據庫中。
在此，先說個現象，C++(其實不只C++是這樣)的面向對象的封裝模型是對數據的封裝，而在數據庫設計中，數據已被放入數據庫中，這沒有矛盾。通過上面所說的“調度過程”可以將數據在C++對象與數據庫間做交換與隔離。如果單純地把數據庫看作是存放數據的場所，那麼這一切都會很單純很美好，可是關系型數據庫要求這些數據要有嚴格的關系，這使得只要關系改變那麼表就要改變，在數據層就要做相應的改變，工作量一下子增加很多，面向對象的封裝本來應該是有很高的重用性與擴展性，可在這裡擴展性受數據影響太大。
舉例：我們按“一張訂單可以訂多個產品”設計完成好一張訂單表，一張產品表與相應的對象設計，但如果需求更改為可以訂購產品的某個零部件，那麼怎麼辦。在這裡，如果原有設計是：訂單，訂購品，訂單量，那麼原有設計不用更改，只要在訂單貨源表中加入零部件就可以完成。訂單貨源表屬於一個索引表指明物料的路徑。從對象的抽象概念講，訂單處理的是訂購品，其不應該說訂單只能訂產品而不能訂零件，產品或零件都屬於一個虛擬的訂購物。這個訂購物可以實例化成產品，也可以實例化為其他。可這裡數據庫的設計不允許這麼做，數據庫的實現只能是引入一張索引表來實現這個抽象的訂購物。雖然還會有其他表設計的實現方式，但是都很難實現面向對象所追求的那種境界，而且引入大量的索引表會對數據庫系統性能有很大影響。除了索引表，第三范式我認為也是面向對象設計的攔路石，於是現有的數據表設計基本上都不是面向對象的設計，都是僵化的設計，對象被凍結在關系中。那麼要面對企業資源中變化莫測的需求關系可以說是捉襟見肘。我想這也是很多人找尋在關系型數據庫中實現面向對象的設計的一個原因。 最後說明：我沒什麼好的見解與辦法去面對這些問題，說的不對希望能指出。我認為封裝數據層並不代表這就是面向對象的設計了，這要看具體的問題領域是樣設計解決的。
(打字打得很累啊)
给大家一个好的网址 www.chinaxp.com
ftp://cinc.3322.org/pub/doc 这个FTP上有很多设计模式与及极限编程的书和文档下载
猛爷请继续
有些啟發，書中關注的中心大致是：界面如何與邏輯分離，實現又如何與具體數據庫分離。我覺得不錯。不過遺憾的是，沒找到我所關注的部分：如何面向對象化地實現用戶的業務邏輯。
因為我認為對於一套軟件：用戶關注的是我的需求(業務邏輯)實現了沒有，當需求變化時，系統能否跟上，最終用戶(使用者)能否把這軟件應用到真實的業務中去。而這種需求，如果能采用面向對象的設計，那才爽。這時就產生了這種難題：無論你的系統如何架構，界面，邏輯，數據庫如何地分離設計，可用戶數據始終被設計成關系型的數據，因為數據最終要存入到關系型數據庫中，這是個難題，也是個必然會遇上的問題。
用代碼實現自己的想法，不怕艱與險，金子要經過磨煉才會發光。希望能看到大家的想法。
现在遇到的困难就是数据绑定的问题，我现在写代码都是写自己的类方法和界面控件绑，总觉得RAD和OO的平衡点很难找，应该有个什么东西使这部分工作简单一些，不是吗？
BORLAND正在发展的ECO技术才刚起步，不过也很有前途，因为有TOGTHER这个MODELING工具的配合。
在DELPHI下的话，目前的BOLD已经算比较成熟了，ECO也是在BOLD基础上发展的。RAD和OO之间还算比较好解决，首先在设计阶段一定要先抛开RAD，不要考虑界面要做成什么样，只要知道界面上需要有哪些内容（即系统输入/输入出项目）即可。用OO的方法实现业务逻辑以后，最后用RAD实现界面，用ORMAPPING等实现数据持久化即完成。当然这只是一种理想化的方法，实践中还是有很多工作要做的。
因為我現有的設計方式還是先設計數據庫，這時就基本定死了業務邏輯，然後才做其他事，整個設計都是圍繞數據庫做的。這樣OO就很難。用ORMAPPING的設計方式，據說是先不用設計表，直接用OO來設計，最後用ORMAPPING來完成表，那樣的話，那些觸發器，貯存過程，視圖這些概念在ORMAPPING中是怎樣的，我想知道的是：ORMAPPING中還有沒有這些概念。我對ORmapping真是一無所知啊。
ORMAPPING的后面还有数据库访问层（如ECO后面是ADO.net等），所以理论上是跟具体数据库没有什么关系的
在ECO中的设计过程是不用考虑DB设计的，只要在TOGTHER中将UML图画好，就能同时生成代码和相应的ECO控件，以及所谓的MetaData Schema（用于生成与ECO对应的数据库结构），至于TRIGGER/VIEW/SP这些都交给ECO去管理维护。
可以这么看，ORMAPPING+RDBMS就是一个OODBMS，这样就可以摆脱RDBMS对OO的影响了。
我大致也就知道这么些，别的还有待研究^_^
1：你的所谓的“不是很成熟的方法”我们的项目中已经在使用这种方式，做了两个中型的系统，感觉很好，另外我们自己写了一个对象生成器来生成实体对象完成数据库的CRUD操作。
2：我现在收集了不少关于ORMap的资料，看过之后决定应该自己实现一部分功能，帮助开发。
你说的对象生成器是不是就是完成对象集和数据集互相转换的东东？
能把你的资料给我发一份吗？
用OO设计DB其实没有什么意义，首先OO思想和RELATIONAL是不太兼容的思想，如果一定要OO，用ORM才是好办法
可能有待于斟酌:-)
无论是在软件工程中，还是在设计模式中，对象模型和数据模型是一个有争议的论题，我们可以不一定要想着用OO去design DB,但是，做为procedure 的DB，它要能真正的达到可以很好的配合Object Model而使软件具有良好的可移值性、扩展性等等，那么，此处我们不得不将一定的精力放在DB上；这是闲话；
程序中用SP的确可以提高效率，但是它只能使软件越来越僵硬，同要View也一样；
先开会去，等会，先Mark;
定义系统中各种商业对象的接口（Interface)，创建对应的商业对象（BO），在BO中实现接口这些接口，并封装这些对象的逻辑，凡是与具体的库表打交道的东西定义成抽像方法。在做具体系统时，子类化那些BO，并实现与数据库打交道的部分。这是我通常的做法，只为懒省劲，少写一点代码，也没考虑什么弹性、复用性之类的。那个太高深了，我还是在小公司里单兵作战，连个人探讨都没有 :(，不知各位大侠都是如何搞的。能否贴出来学习一下。
看的出，大家都对设计模式、软件工程、XP之类的读的很熟悉，因此长篇大论不绝于耳，就像软件工程版里边的一样，可是真正能解决问题的，从小处着手的，好像并不是很多，不像比什么这些资质，因为比起来，你们没有我高，只是就问题分析而来分析
其实，楼主这个问题话的最简单就是如何能够让数据库实现多元化，可以根据不同的要求适合于不同的View,很清楚的一点就是，实现多元化的，一般而言都有Control Object，就是控制,以单纯的数据库构造，很难构造出一个可以适应于多元化的的DB，看了猛鸟所说的ORMAPPING颇有同感，我们需要的就是构造出一个Ormapping,但是，可是也正如楼上的一位仁兄所提及的XP，DB的可变性！在敏捷编程中，我们提倡灵活性，虽然失去了某些原则，但是他的思想值的学习，很深入的学习，DB在编程的过程中尚可变化，因为讨厌DB的固化，而SP,View往往使得一个DB提前的固化，话说了回来，又到了Object Model 、DB Model之中，业务层的业务规则封装已经是一个不可争论的事实，而且，提前构造一个架构就是 Object Model的真正体现，在Object Model中去进一步的理解DB Model的办法有两种，一种是DB的OO化， 另一种是Ormapping，但是DB本身是一个Procedure 型的，要实现OO化，需的是在Object Model中提化出来，而非DB本身上浪费巨大的精力，在DB上，需要做的就是按照业务去娄活的设计；而SP,View本身就是一种固化，它以效率为中心，而以可扩展性、可维护性甚至冗余做为了代价！这是我们一定要避免的，与其这样，我们不如选择层次型数据库。
楼主问的是关于设计模式与数据库,面向对象三者的关系的问题。我认为：
1.面向对象首先一种方法论，是一种分析问题与解决问题的方法。为什么要提出面向对象，就是因为越来越大的企业应用软件，用以前的模块化思想来解决越来越难了。而我们在认识一个大事物的时候，一种比较好的方法，就是把这个大问题分解出小问题，然后逐个搞定。面向对象认为，一个系统可以看成是由对象，以及对象之间的关系组成，这种思路跟前面说的关于分析问题的思路是一样的。所以，面向对象会被逐步流行起来。同时面向对象，具有的封装性，继承性和多态性，大大地提供了系统的可重用性，可扩展性。
2.设计模式是在进行面向对象设计过程中，对一些经验的总结和归纳。其描述了在面向对象系统中不断重复的问题，以及对问题的解决方案。其具有可传授性，一旦提出了一个好的设计模式，我们就可以其他地方进行应用，当然要注意某个设计模式的时机，优点和缺点
3.数据库，现在一般是指关系型数据库，其是保存数据的一种方式。
4.应该说，面向对象跟数据库之间没有必然的联系。面向对象是分析和解决问题的方法，但是我整个系统分析设计成很多对象，以及对象之间的关系后。有些对象我们是需要持久化（表示这个对象一直要保存起来，不应该关机之后，这个对象就永远消失了,机器重启后，这个对象能重新激活，就好像硬盘中的文件一样，而不是内存中的数据）。对象持久化的方式，就可以选择数据库，当然也可以选择XML，文本等。这样，需持久化的对象与数据库之间就有映射处理，就是前面几位大哥说的O/R Mapping。在Java中，有了比较好的O/R框架.但到目前为止，还是没有非常完美的解决方案。期待中.......
这里有一个东西和你们的讨论有些关系.Delphi和
OO,DB和OO这个话题由来已久.希望这里的这个东
西能给大家带来一点帮助或者经验
http://www.2ccc.com/article.asp?articleid=239