首页 新闻 搜索 专区 学院

请问合并业务逻辑层与数据访问层可以吗?!

0
悬赏园豆:10 [已解决问题] 解决于 2009-07-09 09:52

最近在开发项目的时候,在思考一个问题,就是有没有必要把业务逻辑层与数据访问层分离;在我开发的这个项目中,我采用的是codesmith自动生成数据访问层,业务逻辑层,以及一些简单的管理后台,我把生成的代码都放在一个DataProviderBasebase类里面,然后派生了一个空的类DataProvider,这个类是用来由用户编写自定义的代码的,我生成的数据访问层代码已经基本上包含大量的方法和接口,包括GetModelByPk,GetModelsByFk,GetAll,GetFeild,GetCount,GetPaged,GetModelByIX等众多常用的操作和重载,而且大部的的地方是入一个比较开放式的结构体做为参数,是一个SqlStruct实体,这个结构里面包含了commandText,CommandType,SqlParameter这些参数,可以说这个类可以完成所有的sql操作,而这个SqlStruct我是通过一个SqlBuilder语句生成类动态生成了来的!

也就说我只要一个SqlBuilder生成一个SqlStruct传递给相应的DataProviderBase(数据访问层)方法即可获取数据,我现在的想法是把逻辑访BLL层代码放到DataProviderBase的派生类DataProvider中(这个类生成后是空的),这样一个是简化层次结构,大家觉得合适吗?

顺便帮忙分析下,有时想想,业务逻辑层在什么情况下才比较迫切的需要呢?

类结构:

     SqlStruct类:

Code

 

 

 

    SqlBuilder类,用于动态生成sql并返回SqlStruct类的实例

DataProviderBase类就是数据访问的操作了,包括获了实体,列表,统计等一系列的方法

DataProvider类继承自DataProviderBase类,是一个空的函数,主要用来给程序员手工编写代码的我打算是把逻辑层的代码写在这里

 

声明下:现在的项目基本没有数据库变化的可能,用的是sql server 没有特别复杂的逻辑,是一个在线商城!

chen eric的主页 chen eric | 初学一级 | 园豆:4
提问于:2009-07-08 14:40
< >
分享
最佳答案
0

分层不一定就是要你分出命名空间、分出类来,你完全可以通过部分类(partial)将业务逻辑定义在别处。

比如你生成的数据访问层里包含User、Room类,这里面是只包含数据访问的代码的,你可以建一个业务逻辑层专用的目录,在其中创建User、Room的另一部分类,这部分就全是与业务逻辑有关的代码了。

(当然,大解决方案最好都分出独立项目)

而合并的意义是让数据访问与业务逻辑的代码混杂在一起,这并不值得推荐,编写起来并不省事,维护起来却麻烦许多。

斯克迪亚 | 老鸟四级 |园豆:4124 | 2009-07-08 16:34
其他回答(3)
0

合适!

顶呱呱 | 园豆:265 (菜鸟二级) | 2009-07-08 15:17
0

可以不过将来网站升级比较麻烦

YaHa | 园豆:130 (初学一级) | 2009-07-08 16:01
0

业务层,是为了业务,你这里通篇都在讲述数据层,如果你没有什么业务逻辑,仅仅是增删改查,就把业务层去了吧

chenleinet | 园豆:270 (菜鸟二级) | 2009-07-08 20:46
清除回答草稿
   您需要登录以后才能回答,未注册用户请先注册