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();
}

好睏,把這幾天學習的東西總結了下還是收穫不少,雖然對裡面有些東西不是非常的理解,慢慢看看就領悟了,分享給大學一同學習~