asp.net 學習之路 項目整體框架簡單的搭建

最近剛學了些關于asp.net mvc方面的知識,于是了要拿個小項目來練練手,提高下自己的code能力跟思維能力.在此之前做東西都很簡單,直接用動軟那一套生成代碼,生成一個簡單的三層架構作為項目整體的框架,數據庫訪問層用的是ado.net.這么做了感覺挺麻煩,如果要項目要換數據庫,要給數據庫增加表或者給表增加某個字段,或者不使用ado.net用個orm框架來訪問數據庫等等,這樣整體項目該動起來就提別的麻煩,為了解決這一些問題我們需要重新思考怎么搭建.

關于數據庫訪問層

數據庫訪問驅動層--大家都知道EF,NH跟Ado.net或者你自己實現的,這些都是為我們訪問數據庫或對數據庫操作建立了橋梁,當然數據庫也可能是不同的數據庫,這些都是根據項目需求來定的,至于選擇哪個則要視情況而定了.這里我就用了EF--model-first.我是直接在edmx里面設計模型,然后生成實體跟數據庫,具體如下,做了個簡單的權限管理(還沒完全實現)..

代碼如下:

public class BaseRepository<T>:IDAL.IBaseRepository<T> where T:class 
{ 
private DbContext container = EFContentFactory.GetCurrentContext(); 
#region 增加 
public T AddEntity(T entity) 
{ 
container.Set<T>().Add(entity); 
return entity; 
} 
#endregion 
#region 刪除 
public bool DeleteEntity(T entity) 
{ 
container.Set<T>().Attach(entity); 
container.Entry(entity).State = EntityState.Deleted; 
return true; 
} 
#endregion 
#region 修改 
public bool UpdateEntity(T entity) 
{ 
container.Set<T>().Attach(entity); 
container.Entry(entity).State = EntityState.Modified; 
return true; 
} 
#endregion 
#region 查詢 
public IQueryable<T> GetEntities(Func<T, bool> lambdaWhere) 
{ 
IQueryable<T> entities = container.Set<T>().Where(lambdaWhere).AsQueryable(); 
return entities; 
} 
#endregion 
#region 分頁 
public IQueryable<T> GetEntitiesByPageIndex<TS>(int pageIndex, int pageSize, out int totalCount, Func<T, bool> lambdaWhere, Func<T, TS> orderByRole, bool descending) 
{ 
var temp = container.Set<T>().Where(lambdaWhere).AsQueryable(); 
totalCount = temp.Count(); 
if (descending) 
{ 
temp = temp.OrderByDescending(orderByRole) 
.Skip(pageSize * (pageIndex - 1)) 
.Take(pageSize).AsQueryable(); 
} 
else 
{ 
temp = temp.OrderBy(orderByRole) 
.Skip(pageSize * (pageIndex - 1)) 
.Take(pageSize).AsQueryable(); 
} 
return temp; 
} 
#endregion 
} 
 
到這一步我以為自己的數據庫訪問層寫完了,然后可以去寫業務邏輯層的東西了,實則不然,想想看,如果你要換數據庫,或者換成ef或者ado.net 如果按老一套,則整個項目的每一個層都需要去替換,大大的增加了工作量,這里我們可以做個手腳,把數據訪問層再給它抽象出一層來,這就需要用到接口了. 
IDAL.IBaseRepository<T>大體想想看我們的bll層如果沒有接口我們直接這么寫 dal.xxrepository=new xxrepository();老一套的寫法,則跟我前面說的一樣,可維護性替換性大大降低..我們現在可以這么寫 
IDAL.xxrepository=new xxrepository().這樣我們替換DAL層時候 BLL層根部不需要關心你到底是怎么實現的.這一點非常的重要.接口就相當于一個契約,約束了你必須實現哪些功能,我們如果要增加功能可直接在接口中增添,接口需要為部分接口,如我給出的上面代碼一樣,基類需要一個接口,子類也需要.這樣我們就抽象出一個數據庫接口層. 
抽象工廠與簡單工廠 
我們還可以對業務層跟數據庫訪問層再讀的抽象出來,這里我們就需要用到工廠--其實很簡單,從工廠類里面取出來的dal層的類并返回IDAL的接口 
 代碼如下:

public static class ShopDaoFactory 
{ 
public static IUserInfoRepository UserInfoRepository 
{ 
get{return new UserInfoRepository();} 
} 
public static IRoleRepository RoleRepository 
{ 
get{return new RoleRepository();} 
} 
} 
 
那么業務層拿到接口時也不需要關心到底怎么實現的,這樣又是一層的抽象,當然你也可以用抽象工廠,利用反射跟配置外加緩存來實現,不過一般情況下簡單工廠足夠了,這里就相當于一個數據庫訪問層的入口了. 
業務邏輯層的基類與子類　 
當我們實體模型多了的時候我們如果沒有基類,則要寫一堆重復性的東西,我們現在就要把這些重復的性的東西放到基類里面給我們實現,如同Dal層,我們定義了一個基類,但是在BLL層我們會遇到一個問題,IDAL.IBaseRepository<T>怎么獲取從工廠獲得接口了......思考一下.....我們的子類可以知道自己所需要的接口------我們可以做個手腳,讓父類為抽象類,定義一個抽象方法,然后讓子類重寫改方法,并且在構造函數里面調用,因為我們必須用到這個接口,所以必須在構造函數里面 
 代碼如下:

public abstract class BaseService<T> :IBLL.IBaseService<T> where T:class, new () 
{ 
public BaseService() 
{ 
GetInstance(); 
} 
protected IDAL.IDbSession _DbSession = DbSeesionFactory.GetSession(); 
protected IDAL.IBaseRepository<T> CurrentRepository { get; set; } 
public abstract void GetInstance(); 
public IQueryable<T> GetEntities(Func<T, bool> lambdaWhere) 
{ 
//_DbSession.SavaChanges(); 
return CurrentRepository.GetEntities(lambdaWhere); 
} 
public bool DeleteEntity(T entity) 
{ 
CurrentRepository.DeleteEntity(entity); 
return _DbSession.SaveChanges() > 0; 
} 
public bool UpdateEntity(T entity) 
{ 
CurrentRepository.UpdateEntity(entity); 
return _DbSession.SaveChanges() > 0; 
} 
public T AddEntity(T entity) 
{ 
var en = CurrentRepository.AddEntity(entity); 
_DbSession.SaveChanges(); 
return en; 
} 
public IQueryable<T> GetEntitiesByPageIndex<TS>(int pageIndex, int pageSize, out int totalCount, Func<T, bool> lambdaWhere, Func<T, TS> orderByRole, bool descending) 
{ 
return CurrentRepository.GetEntitiesByPageIndex(pageIndex, pageSize, out totalCount, lambdaWhere, orderByRole, 
descending); 
} 
} 
} 
 
其他的業務層也需要接口抽象出一層出來來作為約束,這樣ui層也不需要關心你業務層怎么實現... 
另外一種實現數據庫入口的方試DBSession 
我們先看一個類,dbsession里面有屬性,為接口,對應的該接口所對應的實現類,兩個方法SaveChanges(),與exesql(EF用的5.0+),里面返回的是當前EF線程類上下文的savechange()與執行sql語句的放回值,怎么才能確保當前進程內EF上下文只有一個了,我們看另外一個類. 
 代碼如下:

public partial class DbSession:IDAL.IDbSession 
{ 
#region 代碼生成器生成 
//public IDAL.IRoleRepository RoleRepository 
//{ 
// get { return new RoleRepository();} 
//} 
//public IDAL.IUserInfoRepository UserInfoRepository 
//{ 
// get { return new UserInfoRepository();} 
//} 
#endregion 
public int SaveChanges() 
{ 
return EFContentFactory.GetCurrentContext().SaveChanges(); 
} 
public int ExcuteSql(string strSql, System.Data.Objects.ObjectParameter[] parameters) 
{ 
return EFContentFactory.GetCurrentContext().Database.ExecuteSqlCommand(strSql, parameters); 
} 
} 
public class EFContentFactory 
{ 
public static DbContext GetCurrentContext() 
{ 
DbContext obj = CallContext.GetData("DbContext") as DbContext; 
if (obj==null) 
{ 
obj = new Model.DataContainer(); 
CallContext.SetData("DbContext",obj); 
} 
return obj; 
} 
} 
 
CallContext 是類似于方法調用的線程本地存儲區的專用集合對象，并提供對每個邏輯執行線程都唯一的數據槽。數據槽不在其他邏輯線程上的調用上下文之間共享,這是從msdn上截取的一段話,它有幾個方法,這里面我們用到setdata跟getdata,來確保上下文線程內唯一,同樣的我們讓他接口化,與工廠內實現下-- 
 代碼如下:

public class DbSeesionFactory 
{ 
/// <summary> 
/// 保證線程內dbsession唯一 
/// </summary> 
/// <returns></returns> 
public static IDAL.IDbSession GetSession() 
{ 
IDAL.IDbSession _dbSession = CallContext.GetData("DbSession") as IDbSession; 
if (_dbSession == null) 
{ 
_dbSession = new DbSession(); 
CallContext.SetData("DbSession", _dbSession); 
} 
return _dbSession; 
} 
} 
 
業務層的子類重寫方法時這么來實現,同樣基類加個: protected IDAL.IDbSession _DbSession = DbSeesionFactory.GetSession(); 
 代碼如下:

public partial class ActionInfoService:BaseService<ActionInfo>,IBLL.IActionInfoService 
{ 
public override void GetInstance() 
{ 
CurrentRepository = _DbSession.ActionInfoRepository; 
} 
} 
public partial class R_UserInfo_ActionInfoService:BaseService<R_UserInfo_ActionInfo>,IBLL.IR_UserInfo_ActionInfoService 
{ 
public override void GetInstance() 
{ 
CurrentRepository = _DbSession.R_UserInfo_ActionInfoRepository; 
} 
} 
public partial class RoleService:BaseService<Role>,IBLL.IRoleService 
{ 
public override void GetInstance() 
{ 
CurrentRepository = _DbSession.RoleRepository; 
} 
} 
 
為什么要這么做了?當我們用EF的時候比如一個方法里面要操作多個表,就不斷的需要用到上下文,這樣可以幫我們剩不少事最后直接來個_dbsession.savechange().可以達到批量刪除修改等等操作.具體看我,今天做了個批量刪除的 
 代碼如下:

public int DeleteUsers(List<int> list) 
{ 
foreach (var i in list) 
{ 
_DbSession.UserInfoRepository.DeleteEntity(new UserInfo() {ID = i}); 
} 
return _DbSession.SaveChanges(); 
} 
 
好困,把這幾天學習的東西總結了下還是收獲不少,雖然對里面有些東西不是非常的理解,慢慢看看就領悟了,分享給大學一同學習~

 
 




聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com