数据层应该分为两个部分,这样可以更好的“分工”,各自研究自己的功能
2008-09-23 06:22
281 查看
数据层应该分为两个部分(并不是说一定要变成两层)第一个部分是处理SQL语句,包括存储过程的名称,存储过程的参数(一下的SQL语句都包含存储过程名称和存储过程的参数);第二部分是传递SQL语句的。
我们先说第二部分,这个最典型的就是SQLhelp。他的职责就是接收SQL语句,然后通过ADO.net传递给数据库,如果是select语句的话,需要返回记录集,记录可以放在DataTable里面,也可以用DataReader。但是放不放在实体类里面不是第二个部分的职责。
有一些tx(包括我在内)会写自己的help,自己写的自己用这舒服嘛,基本功能大概也就是我上面说的这些。
这个部分还以一个职责,那就是要支持多种数据库!不过这个也不难,在ADO.net2.0的支持下,也是很简单的。
第一部分就是处理SQL语句的部分,比如我要添加一条新闻,那么就要有这样一条类似的语句
“insert into News (NewsTitle,NewsContent) values (@NewsTitle,@NewsContent) ”。
那么这样的sql语句是如何获得的呢?这个就是第二部分要处理的事情。
这里的变化就有很多了。可以自己手写,可以拼接,可以使用LinQ 、Hibernate等,当然有些也直接把第二部分包含进去了。
相信有好多人就是这么做的,但是也会有些人把这两个部分完全混合在一起了。LinQ 、Hibernate这一类的不知道内部是如何处理的,相信也会由一个明确的区分吧。
分成两个部分的好处就是可以进一步的“优化”(这个词不太准确,没想到太好的词语)。第二部分很容易就做成通用的,这样就大大的减少了代码量,和发开时间,出现bug的概率也会大大降低。
第一部分就可以只考虑如何处理SQL语句了,比如不同的数据库的情况下,如何写sql语句。比如在添加、修改的情况下如何处理sql语句,insert into ...... 是不是所有的数据库都支持。尽量让一种sql语句可以“适合”多种数据库。
如果都支持的话,那么添加数据的情况我是不是只需要写一种SQL语句就可以了,一种SQL语句就可以应对多种数据库。因为这样的话,添加数据的部分我就不必要先定义一个接口,然后在SQL Server 实现一遍接口,Orcale再实现一遍接口,Access再实现一遍接口了。sql语句都是一样的呀(对于添加来说都是insert into ),这样代码量就有节省了一大块。
同理,修改数据(Update)、删除数据(delete)是不是也可以同样处理呢?
剩下来的就是最麻烦的分页了。其实这个也简单,快上班了,先不写了。
对了,还有一些地方,统计报表了、导出数据了、其他一时没先到的地方,这些是不是都可以使用类似的思路来处理一下呢?如果可行的话,那么代码量会减少70%(和petshop相比)。
我们先说第二部分,这个最典型的就是SQLhelp。他的职责就是接收SQL语句,然后通过ADO.net传递给数据库,如果是select语句的话,需要返回记录集,记录可以放在DataTable里面,也可以用DataReader。但是放不放在实体类里面不是第二个部分的职责。
有一些tx(包括我在内)会写自己的help,自己写的自己用这舒服嘛,基本功能大概也就是我上面说的这些。
这个部分还以一个职责,那就是要支持多种数据库!不过这个也不难,在ADO.net2.0的支持下,也是很简单的。
第一部分就是处理SQL语句的部分,比如我要添加一条新闻,那么就要有这样一条类似的语句
“insert into News (NewsTitle,NewsContent) values (@NewsTitle,@NewsContent) ”。
那么这样的sql语句是如何获得的呢?这个就是第二部分要处理的事情。
这里的变化就有很多了。可以自己手写,可以拼接,可以使用LinQ 、Hibernate等,当然有些也直接把第二部分包含进去了。
相信有好多人就是这么做的,但是也会有些人把这两个部分完全混合在一起了。LinQ 、Hibernate这一类的不知道内部是如何处理的,相信也会由一个明确的区分吧。
分成两个部分的好处就是可以进一步的“优化”(这个词不太准确,没想到太好的词语)。第二部分很容易就做成通用的,这样就大大的减少了代码量,和发开时间,出现bug的概率也会大大降低。
第一部分就可以只考虑如何处理SQL语句了,比如不同的数据库的情况下,如何写sql语句。比如在添加、修改的情况下如何处理sql语句,insert into ...... 是不是所有的数据库都支持。尽量让一种sql语句可以“适合”多种数据库。
如果都支持的话,那么添加数据的情况我是不是只需要写一种SQL语句就可以了,一种SQL语句就可以应对多种数据库。因为这样的话,添加数据的部分我就不必要先定义一个接口,然后在SQL Server 实现一遍接口,Orcale再实现一遍接口,Access再实现一遍接口了。sql语句都是一样的呀(对于添加来说都是insert into ),这样代码量就有节省了一大块。
同理,修改数据(Update)、删除数据(delete)是不是也可以同样处理呢?
剩下来的就是最麻烦的分页了。其实这个也简单,快上班了,先不写了。
对了,还有一些地方,统计报表了、导出数据了、其他一时没先到的地方,这些是不是都可以使用类似的思路来处理一下呢?如果可行的话,那么代码量会减少70%(和petshop相比)。
相关文章推荐
- 数据层应该分为两个部分,这样可以更好的“分工”,各自研究自己的功能
- 4程序员小飞原计划三天完成某个任务,现在是第三天的下午,他马上就可以做完。但是在实现功能的过程中,他越来越意识到自己原来设计中的弱点,他应该采取另一个办法,才能避免后面集成阶段的额外工作。但是他如果现在就改弦更张,那势必要影响自己原来估计的准确性,并且会花费额外的时间,这样他的老板、同事也许会因此看不起他。如果他按部就班地按既定设计完成,还要花更多时间在后续集成上,但那就不是他个人的问题了,怎么办
- 什么是理想,理想就是创造和实现,而高层次高境界的理想是追求和达到自我精神中的一种释放,以及对自己的满意程度。怎样让自己活得更好,四个字就可以概括,我想大家应该有自已的答案!
- 可以把 SQL 分为两个部分:数据操作语言 (DML) 和 数据定义语言 (DDL)
- 尽管普通的sql语句代码可以实现数据插入的操作,但是更好的代码应该是参数的方式:
- 将IRepository接口进行抽象,使它成为数据基类的一个对象,这样每个子类都可以有自己的最基础的CURD了
- 菜鸟:自己写了一个轮播代码供分为参考,如果有什么地方你有更好的方法,可以给我留言
- Spring框架中提供了它自己的标签库,可以和相关的组建相结合,可以提供页面表单组件、错误信息的数据绑定等功能。
- 欧拉计划37题:找出全部11个这样从左向右和从右向左都可以裁剪的质数,shift函数的学习,从别人的答案提取精华,自己的思路和扩展的思路就是两个思路
- 空间换时间思维——筛选法——N内求素数——一定要自己想,抄出来那部分代码拼接貌似可以,但不能写出来
- 自己实现一个bubble_sort(冒泡排序),可以完成不同类型数据的排序
- HTML:如何将网页分为上下两个部分
- Elasticsearch 两个可以用于压缩数据尺寸的特性
- 创建一个CPoint类,代表平面直角坐标系中的点,创建构造函数和运算符重载函数, 运算符重载为类重载(非友元重载),可以实现计算两个点之间的距离。可以根据需要 加入自己的成员变量或成员函数
- 我们都会有这样的经历,当觉得别人写的某个功能不错时,把demo移植到自己的工程中,其中的某些点9点png图片会报如下的错误
- GET请求和POST请求有什么区别?GET请求的参数在URL的问号后面显示,而POST参数不在URL上;POST可以比GET请求更大的数据…一般的回答都是这样。 但是作为一个高端大气上档次的程序
- jfinal事务小例子,事务,是要自己写的,框架可以代劳部分工作,但是不能替代你写事务,程序员是要做工作的
- 大学生活应该这样度过之参加一个社团让自己溶入团队——《程序员羊皮卷》连载(11)
- (编程解决)List和Hashtable都是可以存储数据的,可为什么有时选择List,有时需要Hashtable,这两个有什么区别?
- 为什么很多时候我们在传输数据的时候都使用base64编码,因为这样我们可以减少数据量的传输。