数据库与面向对象是冤家

liugmwx 发表于 2007-11-8 21:43:48

<DIV class=storytext>
面向对象和数据库之间存在着矛盾。这正是我们学习了面向对象理论之后，信心百倍地要去做项目时，突然发现有很多问题的原因…… 
　　话说当年面向对象和数据库刚出道的时候，曾经引发过惊天动地的大讨论（当然，这里说的是关系型数据库，以下简称数据库）。两个阵营的人都试图说服对方，加入到自己的阵营里来（传说是都说了，你别做了那个了，没发展）。经过车轮式讨论，也没得到共识，只好分道扬镳了。。。。。。

 
面向对象和数据库之间存在着矛盾。这正是我们学习了面向对象理论之后，信心百倍地要去做项目时，突然发现有很多问题的原因……
　　话说当年面向对象和数据库刚出道的时候，曾经引发过惊天动地的大讨论（当然，这里说的是关系型数据库，以下简称数据库）。两个阵营的人都试图说服对方，加入到自己的阵营里来（传说是都说了，你别做了那个了，没发展）。经过车轮式讨论，也没得到共识，只好分道扬镳了。
　　虽然，无法考证这个传说是不是真的，但确实，面向对象和数据库之间存在着矛盾。这正是我们学习了面向对象理论之后，信心百倍地要去做项目时，突然发现有很多问题的原因。
　　要是世界上只有面向对象，或则只有数据库，那该多好啊？但这只是奢望罢了。既然矛盾并共存着，那就只能取长补短了。
　　让面向对象和数据库，好好合作
　　大家有没有觉得，类图和ER图画出来之后，是不是很像？矛盾就在这里，数据库阵营的人认为，面向对象做得是在内存中建立一个新的数据库，浪费了资源。而面向对象阵营的人认为面向对象更符合人的思维模式、可以开发出更健壮的系统。
　　先看一下面向对象和数据库的优点吧。面向对象的优点在于模块化和处理复杂的业务逻辑，而数据库的优点在于数据存储、查询、统计。
　　解决一个问题，不是只有一种方法，不能说哪一个方法是万能药。每一个方法都有它存在的意义。
　　面向对象和数据库各有其特长，何不让它们发挥各自的特长呢？
　　面向对象，你就处理复杂的业务逻辑~
　　数据库，你就处理数据的查询、统计、简单的业务逻辑~
　　好，首先大的方向已经明确了，但开始做项目之前还要明确以下几点，当需要时，才加载，类有属性和方法，下面定义了一个客户类，

<TABLE cellSpacing=1 cellPadding=0 width="80%" bgColor=#cccccc>
<TBODY>
<TR>
<TD bgColor=#f2f2f2><PRE>// 客户类 　　class Customer 　　{ 　　Public int Id; //客户ID 　　Public String Name;//客户姓名 　　// 取客户的销售额 　　public bool GetSaleAmount(); 　　}</PRE></TD></TR></TBODY></TABLE>
　　我现在要查询客户的销售额，那么Id和Name对我来说是没有意义的。如果不是数据库编程，这都是无关紧要的，但数据库编程中，属性的数据保存在数据库里，所以每生成一个对象，都要去查询数据库的话，系统的性能肯定大打折扣。看一下修改后的类

<TABLE cellSpacing=1 cellPadding=0 width="80%" bgColor=#cccccc>
<TBODY>
<TR>
<TD bgColor=#f2f2f2><PRE>// 客户类 　　class Customer 　　{ 　　// 取客户信息 　　public DataSet GetInfo (); 　　// 取客户的销售额 　　public bool GetSaleAmount(); 　　}</PRE></TD></TR></TBODY></TABLE>
　　类中把Id和Name属性去掉，然后加了一个GetInfo方法。现在好了，生成客户对象，不会进行数据库查询，当需要客户信息时，可以调用GetInfo方法来获得。这种方法看起来，不像是面向对象的，因为它没有属性，面向对象是思想、理论，理论要联系实际，根据实际情况取舍一些东西是无可厚非的，况且，这样做也不会丢掉面向对象的优点（还可以用，继承、多态等等）。
　　用什么来传递数据，编程工具都有数据库控件，比如。NET有DataSet，Delphi有TTable、TQuery等等。那，是使用数据库控件还是使用对象？应该是从它们的优点去出发来决定用哪一个。对象结构简单，操作起来非常方便，而且直观。数据库控件虽然结构复杂，操作不方便，但处理大量数据是它的优势。所以传递单条记录时使用对象，传递一组记录的时候使用数据库控件是一个不错的方法。
　　当然传递一组记录时也可以用对象，把对象装在容器里，然后传递。但要考虑一下几点，只是为了显示吗？那就大可不必，因为它的功能只是显示，数据库控件可以做得很好，而且不需要额外的工作。要用这些对象做统计操作吗？那就需要考虑效率问题了，数据传输和对象生成，需要消耗更多的资源。而且统计是数据库的强项，为什么放着能干的人，不用呢？
　　一般常用的业务逻辑类编写方式
　　用类把你的函数封装起来
　　方法：声明一个static类，然后把函数放到类里。不要说这个太不像面向对象了，类是一个模块，能准确定义一个类是面向对象中最困难的事情。
　　数据处理：手写SQL
　　数据容器：编程工具提供的数据库控件。

<TABLE cellSpacing=1 cellPadding=0 width="80%" bgColor=#cccccc>
<TBODY>
<TR>
<TD bgColor=#f2f2f2><PRE>// 客户类 　　static class Customer 　　{ 　　// 输入客户信息 　　static public bool Insert(int Id,int Name) 　　{ 　　} 　　// 更新客户信息 　　static public bool Update(int Id,int Name) 　　{ 　　} 　　//删除客户信息 　　static public bool Delete(int Id) 　　{ 　　} 　　//获得客户信息 　　static public DataSet GetInfo(int Id) 　　{ 　　} 　　//获得客户列表 　　public DataSet GetList() 　　{ 　　} 　　}</PRE></TD></TR></TBODY></TABLE>
　　优点
　　- 对面向对象理论方面要求不高，通过短时间学习，就可以掌握
　　- 代码简单易懂
　　- 代码效率高
　　缺点
　　- 不能充分发挥面向对象的特点
　　- Update和Insert把数据库字段作为参数，当添加字段或删除字段时，需要修改函数。

发挥面向对象和数据库的特点
　　方法：声明一个Entity类和一个业务逻辑类
　　数据处理：手写SQL
　　数据容器：插入、更新、传递单条记录使用Entity对象，一组记录使用数据库控件

<TABLE cellSpacing=1 cellPadding=0 width="80%" bgColor=#cccccc>
<TBODY>
<TR>
<TD bgColor=#f2f2f2><PRE>// 客户Entity 　　class CustomerEntity 　　{ 　　public int Id; 　　public string Name; 　　} 　　// 客户类 　　class Customer 　　{ 　　*** int Id; 　　//构造 　　public Customer(int Id) 　　{ 　　this.Id = Id; 　　} 　　// 输入客户信息 　　public bool Insert(CustomerEntity CustEntity) 　　{ 　　} 　　// 更新客户信息 　　public bool Update(CustomerEntity CustEntity) 　　{ 　　} 　　//删除客户信息 　　public bool Delete() 　　{ 　　} 　　//获得客户信息 　　public CustomerEntity GetInfo() 　　{ 　　} 　　//获得客户列表 　　public DataSet GetList() 　　{ 　　} 　　}</PRE></TD></TR></TBODY></TABLE>
　　优点
　　- 能发挥面向对象和数据库各自的特点
　　- 代码效率高
　　缺点
　　- 需要比较全面的面向对象理论
　　- 使用了Entity类，需要自动生成工具
　　使用O/R Mapping 工具
　　方法：使用O/R Mapping工具
　　数据处理：O/R Mapping 工具自动处理
　　数据容器：对象

<TABLE cellSpacing=1 cellPadding=0 width="80%" bgColor=#cccccc>
<TBODY>
<TR>
<TD bgColor=#f2f2f2><PRE>// 客户类 　　class Customer 　　{ 　　public int Id; 　　public string Name; 　　// 输入客户信息 　　public bool Insert(CustomerEntity CustEntity) 　　{ 　　} 　　// 更新客户信息 　　public bool Update(CustomerEntity CustEntity) 　　{ 　　} 　　//删除客户信息 　　public bool Delete() 　　{ 　　} 　　//获得客户信息 　　public CustomerEntity GetInfo() 　　{ 　　} 　　//获得客户列表 　　public IList GetList() 　　{ 　　} 　　} </PRE></TD></TR></TBODY></TABLE>
　　优点
　　- 能发挥面向对象特点
　　- 可以自动把对象模型转换到数据模型
　　- 能自动处理，简单的CURD
　　缺点
　　- 需要很高的能力和耐心
　　- 流行的O/R Mapping 工具都是开源出来的，没有保障
　　- 还不是很完善，存在不可预测的危险
　　- 对于处理复杂的对象关系，配置复杂
　　- 需要额外学习O/R Mapping 方面的知识
　　那到底该用什么样的方式？
　　采用什么样的方式，实际上说，主要还是在人，而不是在技术。确定使用哪种方式之前，可以考虑以下几个问题，
　　- 使用它的目的是什么？
　　- 对它了如指掌吗？如果出现问题，能马上解决吗？
　　- 它简单吗？初学的人需要多长时间，才能掌握？
　　- 跟所有人达成共识了吗？有没有抵触的人？
　　不要让项目成为你练手的试验品，不要让底下的人每天处理80%的工具问题，只处理20%的业务逻辑。业务逻辑才是客户需要的东西。
</DIV>

leizhe 发表于 2009-4-27 10:00:35

thx a lot

页: [1]

栖息谷-管理人的网上家园's Archiver

数据库与面向对象是冤家