.NET 分布式架构开发实战之四 构建从理想和实现之间的桥梁(前篇)
一般的Add方法都是返回添加是否成功,true或者false,方法再次改造:
bool AddSingleDataEntity<T>(T dataEntity) where T:IDataEntity,class,new();
然后Richard就写出了上面列出的一些方法的定义:
bool AddSingleDataEntity<T>(T dataEntity) where T : class,IDataEntity, new();
bool AddDataEntityList<T>(List<T> dataEntityList) where T : class,IDataEntity, new();
bool DeleteDataEntityList<T>(List<T> dataEntityList) where T : class,IDataEntity, new();
bool DeleteSingleDataEntity<T>(T dataEntity) where T : class,IDataEntity, new();
bool UpdateSingleDataEntity<T>(T dataEntity) where T : class,IDataEntity, new();
bool UpdateDataEntityList<T>(List<T> dataEntityList) where T : class,IDataEntity, new();
至于GetDataEntityList,按照之前的查询对象的想法,传入一个IQuery的接口:
List<T> GetDataEntityList<T>(IQuery query)where T : class,IDataEntity, new();
2. 对基本的操作的进一步的思考
确实,上面那些基本操作是没有什么问题的,现在Richard又考虑到了另外的一些问题,还是以AddSingleDataEntity方法为例:
a. 有些时候,不仅仅要知道插入数据是否成功,而且还想返回新加入数据在数据库中的主键信息来做其他的用途。怎么办?再来查询一次?
b. 如果插入失败了,仅仅只是返回一个false吗?可能其他的调用模块想知道到底是发生了什么异常而导致的插入失败,而且其他的模块对于发生的异常有自己的处理方法,所以AddSingleDataEntity要提供足够的信息。
基于上面的思考,所以这个基本的操作方法不能只是简单的返回一些简单的值就完了。也就是说,这些方法要返回一个数据包:里面包含很多信息,以便其他的调用模块来使用这些信息,感觉有点像是C#事件中的eventArgs.
所以Richard在Common的那个类库中加入一个对象,定义如下:
代码
public class DataResult<T> where T : IDataEntity { public List<T> EntityList { get; set; } public bool IsSuccess { get; set; } public Exception Exception { get; set; } public object CustomData { get; set; } }
这个类最后将会作为方法的返回结果。
Richard发觉,上面的方法确实是很有”自解释性”,但是很多的开发人员对这些CRUD操作的名字都很熟悉了,而且最后开发的出来的架构的使用者还是开发人员,应该符合他们的习惯,所以Richard改变了方法的名字,改变后的版本如下:
代码
public interface IDataContext { IList<T> Query<T>(IQuery queryCondition) where T : class,IDataEntity, new(); IList<T> Query<T>(IQuery queryCondition, int pageIndex, int pageCount) where T : class,IDataEntity, new(); // CRUD services (well, mostly CUD) T Add<T>(T item) where T : class,IDataEntity, new(); IList<T> Add<T>(List<T> itemList) where T : class,IDataEntity, new(); bool Delete<T>(List<T> itemList) where T : class,IDataEntity, new(); bool Delete<T>(T item) where T : class,IDataEntity, new(); T Update<T>(T item) where T : class,IDataEntity, new(); List<T> Update<T>(List<T> itemList) where T : class,IDataEntity, new(); }
3. 查询对象的一些思考
在上面的基本的操作中,在Query方法中传入的是查询对象,因为查询对象是基于解释器的,可以在解释完查询对象之后就缓存起来。以后再次查询的时候,如果两个查询的对象一样(例如在构造查询对象时候,可以为其定义一个唯一的标示),那么就不用再去对查询对象进行解释。如果根据这个查询对象的查出的数据都是只读的,那就更好了,就可以把查询对象和对应的结果一起缓存起来。
今天就先写到这里了,下一篇:
.NET 分布式架构开发实战之四 构建从理想和实现之间的桥梁(中篇)—DAL的基本方法的重构
谢谢各位!
转载:http://www.cnblogs.com/yanyangtian/archive/2010/05/28/1746334.html
本文链接:http://www.blueidea.com/tech/program/2010/7755.asp
出处:博客园
责任编辑:bluehearts
上一页 .NET分布式架构开发实战(四) 前篇 [1] 下一页
◎进入论坛网络编程版块参加讨论
|