面向对象和数据库之间存在着矛盾这正是我们学习了面向对象理论之后信心百倍地要去做项目时突然发现有很多问题的原因……
话说当年面向对象和数据库刚出道的时候曾经引发过惊天动地的大讨论（当然这里说的是关系型数据库以下简称数据库）两个阵营的人都试图说服对方加入到自己的阵营里来（传说是都说了你别做了那个了没发展）经过车轮式讨论也没得到共识只好分道扬镳了
虽然无法考证这个传说是不是真的但确实面向对象和数据库之间存在着矛盾这正是我们学习了面向对象理论之后信心百倍地要去做项目时突然发现有很多问题的原因
要是世界上只有面向对象或则只有数据库那该多好啊？但这只是奢望罢了既然矛盾并共存着那就只能取长补短了
让面向对象和数据库好好合作
大家有没有觉得类图和ER图画出来之后是不是很像？矛盾就在这里数据库阵营的人认为面向对象做得是在内存中建立一个新的数据库浪费了资源而面向对象阵营的人认为面向对象更符合人的思维模式可以开发出更健壮的系统
先看一下面向对象和数据库的优点吧面向对象的优点在于模块化和处理复杂的业务逻辑而数据库的优点在于数据存储查询统计
解决一个问题不是只有一种方法不能说哪一个方法是万能药每一个方法都有它存在的意义
面向对象和数据库各有其特长何不让它们发挥各自的特长呢？
面向对象你就处理复杂的业务逻辑~
数据库你就处理数据的查询统计简单的业务逻辑~
好首先大的方向已经明确了但开始做项目之前还要明确以下几点当需要时才加载 类有属性和方法下面定义了一个客户类
//客户类
classCustomer
{
PublicintId;//客户ID
PublicStringName;//客户姓名
//取客户的销售额
publicboolGetSaleAmount();
}
我现在要查询客户的销售额那么Id和Name对我来说是没有意义的如果不是数据库编程这都是无关紧要的但数据库编程中属性的数据保存在数据库里所以每生成一个对象都要去查询数据库的话系统的性能肯定大打折扣看一下修改后的类
//客户类
classCustomer
{
//取客户信息
publicDataSetGetInfo();
//取客户的销售额
publicboolGetSaleAmount();
}
类中把Id和Name属性去掉然后加了一个GetInfo方法现在好了生成客户对象不会进行数据库查询当需要客户信息时可以调用GetInfo方法来获得这种方法看起来不像是面向对象的因为它没有属性面向对象是思想理论理论要联系实际根据实际情况取捨一些东西是无可厚非的况且这样做也不会丢掉面向对象的优点（还可以用继承多态等等）
用什么来传递数据 编程工具都有数据库控件比如NET有DataSetDelphi有TTableTQuery等等那是使用数据库控件还是使用对象？应该是从它们的优点去出发来决定用哪一个对象结构简单操作起来非常方便而且直观数据库控件虽然结构复杂操作不方便但处理大量数据是它的优势所以传递单条记录时使用对象传递一组记录的时候使用数据库控件是一个不错的方法
当然传递一组记录时也可以用对象把对象装在容器里然后传递但要考虑一下几点只是为了显示吗？那就大可不必因为它的功能只是显示数据库控件可以做得很好而且不需要额外的工作要用这些对象做统计操作吗？那就需要考虑效率问题了数据传输和对象生成需要消耗更多的资源而且统计是数据库的强项为什么放着能干的人不用呢？
一般常用的业务逻辑类编写方式
用类把你的函数封装起来
方法声明一个static类然后把函数放到类里不要说这个太不像面向对象了类是一个模块能准确定义一个类是面向对象中最困难的事情
数据处理手写SQL
数据容器编程工具提供的数据库控件
//客户类
staticclassCustomer
{
//输入客户信息
staticpublicboolInsert(intIdintName)
{
}
//更新客户信息
staticpublicboolUpdate(intIdintName)
{
}
//删除客户信息
staticpublicboolDelete(intId)
{
}
//获得客户信息
staticpublicDataSetGetInfo(intId)
{
}
//获得客户列表
publicDataSetGetList()
{
}
}
优点
对面向对象理论方面要求不高通过短时间学习就可以掌握
代码简单易懂
代码效率高
缺点
不能充分发挥面向对象的特点
Update和Insert把数据库字段作为参数当添加字段或删除字段时需要修改函数
发挥面向对象和数据库的特点
方法声明一个Entity类和一个业务逻辑类
数据处理手写SQL
数据容器插入更新 传递单条记录使用Entity对象一组记录使用数据库控件
//客户Entity
classCustomerEntity
{
publicintId;
publicstringName;
}
//客户类
classCustomer
{
privateintId;
//构造
publicCustomer(intId)
{
thisId=Id;
}
//输入客户信息
publicboolInsert(CustomerEntityCustEntity)
{
}
//更新客户信息
publicboolUpdate(CustomerEntityCustEntity)
{
}
//删除客户信息
publicboolDelete()
{
}
//获得客户信息
publicCustomerEntityGetInfo()
{
}
//获得客户列表
publicDataSetGetList()
{
}
}
优点
能发挥面向对象和数据库各自的特点
代码效率高
缺点
需要比较全面的面向对象理论
使用了Entity类需要自动生成工具
使用O/R Mapping 工具
方法使用O/R Mapping工具
数据处理O/R Mapping 工具自动处理
数据容器对象
//客户类
classCustomer
{
publicintId;
publicstringName;
//输入客户信息
publicboolInsert(CustomerEntityCustEntity)
{
}
//更新客户信息
publicboolUpdate(CustomerEntityCustEntity)
{
}
//删除客户信息
publicboolDelete()
{
}
//获得客户信息
publicCustomerEntityGetInfo()
{
}
//获得客户列表
publicIListGetList()
{
}
}
优点
能发挥面向对象特点
可以自动把对象模型转换到数据模型
能自动处理简单的CURD
缺点
需要很高的能力和耐心
流行的O/R Mapping 工具都是开源出来的没有保障
还不是很完善存在不可预测的危险
对于处理复杂的对象关系配置复杂
需要额外学习O/R Mapping 方面的知识
那到底该用什么样的方式？
采用什么样的方式实际上说主要还是在人而不是在技术确定使用哪种方式之前可以考虑以下几个问题
使用它的目的是什么？
对它了如指掌吗？如果出现问题能马上解决吗？
它简单吗？初学的人需要多长时间才能掌握？
跟所有人达成共识了吗？有没有抵触的人？
不要让项目成为你练手的试验品不要让底下的人每天处理%的工具问题只处理%的业务逻辑业务逻辑才是客户需要的东西
