[原创].NET 业务框架开发实战之六 DAL的重构
2010-06-03 07:18
316 查看
.NET 业务框架开发实战之六 DAL的重构
前言:其实这个系列还是之前的".NET 分布式架构开发实战 ",之所以改了名字,主要是因为文章的标题带来了不少的歧义:系列文章中本打算开发一个简化业务发的流程的Framework,然后用这个Framework再来实战,开发一个分布式的应用。改了名字。给大家带来了不便,敬请见谅。
本篇的议题如下:
1. 确定DAL的接口的定义。
系列文章链接:
[原创].NET 分布式架构开发实战之一 故事起源
[原创].NET 分布式架构开发实战之二 草稿设计
[原创].NET 分布式架构开发实战之三 数据访问深入一点的思考
[原创].NET 分布式架构开发实战之四 构建从理想和实现之间的桥梁(前篇)
[原创].NET 分布式架构开发实战五 Framework改进篇
[原创].NET 业务框架开发实战之六 DAL的重构
[原创].NET 业务框架开发实战之七 业务层初步构想
[原创].NET 业务框架开发实战之八 业务层Mapping的选择策略
[原创].NET 业务框架开发实战之九 Mapping属性原理和验证规则的实现策略
[原创].NET 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(前篇)
[原创].NET 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(后篇)
之前在开发DAL中,提出了一些思想,也设计了一些接口。现在就把DAL的一些设计完善起来。说是“完善”,并不是说把所有的代码都实现,而是把该定义的接口,方法敲定下来。Richard认为,设计一个架构或者Framework的时候,开始是接口的定义,定义好各层之间交互的接口,然后才是具体代码的实现。
因为在设计Framework的时候,首先要考虑这个Framework的使用者是谁,希望他们怎么样来使用开发出来的这个Framework。在这里,Richard很明白:Framework的使用者就是自己公司里的开发人员。而且还要使得开发的使用尽量的方便,不要到处去配置一些文档,最好就是把Framework引入进来,稍微配一下就使用。
在Richard设计的Framework中,就DAL而言,如果希望DAL返回DataTable,DataReader等给BLL,那么需要配置的仅仅只是指明数据库的连接字符串;如果希望DAL返回的数据实体给BLL,那么就得把一张张的表映射成为实体,然后让这些实体继承IDataEntity接口就行了(生成实体可以用ORM工具,或者自己手写代码)。
Richard思考了之前对DAL的设计,在此他做了一些改进。
首先就是对于IDataContext的重新设计和理解:之前的设计是定义了IDataContext,然后用不同的方式实现这个接口,如LinqDataContext.Provider就是用Linq的方法来返回结果(DataResult)。现在Richard认为IDataContext其实就是用来操作数据库的,所以返回的结果就应该是操作数据之后的结果,如Update操作就返回受影响的行数或者是否更新成功。至于是否要把一些额外的信息包装返回给BLL,就不是IDataContext的实现者的事情了。而且Richard还考虑到了需要在一定程度上支持原生的ADO.NET,起码给ADO.NET预留接口。
基于此,Richard就把IDataContext定义为一个接口声明,然后再定义了IDataEntityContext,和IDataTableContext来继承IDataContext,他们的关系图如下:
代码
/// <summary>
/// 数据提供者要实现的借口
/// </summary>
public interface IDataProvider
{
DataResult<TEntity> Add<TEntity>(TEntity entity) where TEntity : IDataEntity;
DataResult<TEntity> Add<TEntity>(List<TEntity> entityList) where TEntity : IDataEntity;
DataResult<TEntity> Update<TEntity>(TEntity entity) where TEntity : IDataEntity;
DataResult<TEntity> Update<TEntity>(List<TEntity> entityList) where TEntity : IDataEntity;
bool Update(ICriteria condiftion, object value);
DataResult<TEntity> Delete<TEntity>(TEntity entity) where TEntity : IDataEntity;
DataResult<TEntity> Delete<TEntity>(List<TEntity> entityList) where TEntity : IDataEntity;
bool Delete(ICriteria condiftion);
int GetCount(ICriteria condition);
DataResult<TEntity> GetOne<TEntity>(ICriteria condition) where TEntity : IDataEntity;
DataResult<TEntity> GetList<TEntity>(ICriteria condition) where TEntity : IDataEntity;
DataResult<TEntity> GetPageData<TEntity>(ICriteria condition, int pageIndex, int pageSize, ref int entityCount) where TEntity : IDataEntity;
List<object> GetCustomData(ICriteria condiftion);
}
之所以要定义这个接口,其实 Richard就是想让实现了IDataContext的类踏踏实实的去做底层的数据操作,至于数据操作之后的结果以什么形式给BLL,不用IDataContext的实现者来关心,而是用IDataProvider的实现者来关心。
在IDataProvider的实现者在底层就是调用了IDataContext的实现者的方法,然后在IDataProvider中,对外提供了一些更加友好和方便使用的方法,最后在BLL中直接依赖的就是IDataProvider,而不是IDataContext。
另外,对于IDataProvider返回的DataResult也做了一些修改:如果返回的是数据实体,即 使用的是IDataEntityContext来提供底层的数据操作,那么DataResult<TEntity>是没有问题的;但是如果使用的是IDataTableContext,那么返回DataResult<TEntity>就不行了,因为IDataTableContext查询方法可能返回的DataTable,或者DataReader.所以,在设计中叶预留了一个接口:让IDataProvider返回的结果实现IDataResult接口,那么ataResult<TEntity>继承这个接口,主要用来返回数据实体,如下:
DAL的设计就到这里,下一篇文章就开始讲述对业务层的一些思考。
版权为小洋和博客园所有,转载请标明出处给作者。
http://www.cnblogs.com/yanyangtian
代码下载
前言:其实这个系列还是之前的".NET 分布式架构开发实战 ",之所以改了名字,主要是因为文章的标题带来了不少的歧义:系列文章中本打算开发一个简化业务发的流程的Framework,然后用这个Framework再来实战,开发一个分布式的应用。改了名字。给大家带来了不便,敬请见谅。
本篇的议题如下:
1. 确定DAL的接口的定义。
系列文章链接:
[原创].NET 分布式架构开发实战之一 故事起源
[原创].NET 分布式架构开发实战之二 草稿设计
[原创].NET 分布式架构开发实战之三 数据访问深入一点的思考
[原创].NET 分布式架构开发实战之四 构建从理想和实现之间的桥梁(前篇)
[原创].NET 分布式架构开发实战五 Framework改进篇
[原创].NET 业务框架开发实战之六 DAL的重构
[原创].NET 业务框架开发实战之七 业务层初步构想
[原创].NET 业务框架开发实战之八 业务层Mapping的选择策略
[原创].NET 业务框架开发实战之九 Mapping属性原理和验证规则的实现策略
[原创].NET 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(前篇)
[原创].NET 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(后篇)
之前在开发DAL中,提出了一些思想,也设计了一些接口。现在就把DAL的一些设计完善起来。说是“完善”,并不是说把所有的代码都实现,而是把该定义的接口,方法敲定下来。Richard认为,设计一个架构或者Framework的时候,开始是接口的定义,定义好各层之间交互的接口,然后才是具体代码的实现。
因为在设计Framework的时候,首先要考虑这个Framework的使用者是谁,希望他们怎么样来使用开发出来的这个Framework。在这里,Richard很明白:Framework的使用者就是自己公司里的开发人员。而且还要使得开发的使用尽量的方便,不要到处去配置一些文档,最好就是把Framework引入进来,稍微配一下就使用。
在Richard设计的Framework中,就DAL而言,如果希望DAL返回DataTable,DataReader等给BLL,那么需要配置的仅仅只是指明数据库的连接字符串;如果希望DAL返回的数据实体给BLL,那么就得把一张张的表映射成为实体,然后让这些实体继承IDataEntity接口就行了(生成实体可以用ORM工具,或者自己手写代码)。
Richard思考了之前对DAL的设计,在此他做了一些改进。
首先就是对于IDataContext的重新设计和理解:之前的设计是定义了IDataContext,然后用不同的方式实现这个接口,如LinqDataContext.Provider就是用Linq的方法来返回结果(DataResult)。现在Richard认为IDataContext其实就是用来操作数据库的,所以返回的结果就应该是操作数据之后的结果,如Update操作就返回受影响的行数或者是否更新成功。至于是否要把一些额外的信息包装返回给BLL,就不是IDataContext的实现者的事情了。而且Richard还考虑到了需要在一定程度上支持原生的ADO.NET,起码给ADO.NET预留接口。
基于此,Richard就把IDataContext定义为一个接口声明,然后再定义了IDataEntityContext,和IDataTableContext来继承IDataContext,他们的关系图如下:
代码
/// <summary>
/// 数据提供者要实现的借口
/// </summary>
public interface IDataProvider
{
DataResult<TEntity> Add<TEntity>(TEntity entity) where TEntity : IDataEntity;
DataResult<TEntity> Add<TEntity>(List<TEntity> entityList) where TEntity : IDataEntity;
DataResult<TEntity> Update<TEntity>(TEntity entity) where TEntity : IDataEntity;
DataResult<TEntity> Update<TEntity>(List<TEntity> entityList) where TEntity : IDataEntity;
bool Update(ICriteria condiftion, object value);
DataResult<TEntity> Delete<TEntity>(TEntity entity) where TEntity : IDataEntity;
DataResult<TEntity> Delete<TEntity>(List<TEntity> entityList) where TEntity : IDataEntity;
bool Delete(ICriteria condiftion);
int GetCount(ICriteria condition);
DataResult<TEntity> GetOne<TEntity>(ICriteria condition) where TEntity : IDataEntity;
DataResult<TEntity> GetList<TEntity>(ICriteria condition) where TEntity : IDataEntity;
DataResult<TEntity> GetPageData<TEntity>(ICriteria condition, int pageIndex, int pageSize, ref int entityCount) where TEntity : IDataEntity;
List<object> GetCustomData(ICriteria condiftion);
}
之所以要定义这个接口,其实 Richard就是想让实现了IDataContext的类踏踏实实的去做底层的数据操作,至于数据操作之后的结果以什么形式给BLL,不用IDataContext的实现者来关心,而是用IDataProvider的实现者来关心。
在IDataProvider的实现者在底层就是调用了IDataContext的实现者的方法,然后在IDataProvider中,对外提供了一些更加友好和方便使用的方法,最后在BLL中直接依赖的就是IDataProvider,而不是IDataContext。
另外,对于IDataProvider返回的DataResult也做了一些修改:如果返回的是数据实体,即 使用的是IDataEntityContext来提供底层的数据操作,那么DataResult<TEntity>是没有问题的;但是如果使用的是IDataTableContext,那么返回DataResult<TEntity>就不行了,因为IDataTableContext查询方法可能返回的DataTable,或者DataReader.所以,在设计中叶预留了一个接口:让IDataProvider返回的结果实现IDataResult接口,那么ataResult<TEntity>继承这个接口,主要用来返回数据实体,如下:
DAL的设计就到这里,下一篇文章就开始讲述对业务层的一些思考。
版权为小洋和博客园所有,转载请标明出处给作者。
http://www.cnblogs.com/yanyangtian
代码下载
相关文章推荐
- [原创].NET 业务框架开发实战之六 DAL的重构
- [原创].NET 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(前篇)
- [原创].NET 业务框架开发实战之八 业务层Mapping的选择策略
- .NET 业务框架开发实战之六 DAL的重构
- [原创].NET 业务框架开发实战之九 Mapping属性原理和验证规则的实现策略
- [原创].NET 业务框架开发实战之七 业务层初步构想
- [原创].NET 业务框架开发实战之八 业务层Mapping的选择策略
- [原创].NET 业务框架开发实战之七 业务层初步构想
- [原创].NET 业务框架开发实战之九 Mapping属性原理和验证规则的实现策略
- [原创].NET 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(前篇)
- .NET 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(后篇)
- .NET 业务框架开发实战之七 业务层初步构想
- .NET 业务框架开发实战之十 第一阶段总结,深入浅出,水到渠成(前篇)
- .NET 业务框架开发实战之九 Mapping属性原理和验证规则的实现策略
- .NET 业务框架开发实战之八 业务层Mapping的选择策略
- .NET 业务框架开发实战
- [原创].NET 分布式架构开发实战之四 构建从理想和实现之间的桥梁(前篇)
- RDIFramework.NET ━ .NET快速信息化系统开发框架 V3.2->Web版本工作流部分业务处理界面与查看界面全新展示
- RDIFramework.NET ━ .NET快速信息化系统开发框架 ━ 工作流程组件WinForm业务平台
- [原创].NET 分布式架构开发实战之一 故事起源