學習asp.net 已經有近三個月的時間了，在asp.net mvc上花的時間最多，但個人真是有些菜，不得不說，asp.net mvc的水真的還是蠻深的。目前在公司實習，也見過公司幾個項目的代碼了。對項目的代碼始終停留在一知半解的地步，能改一些簡單的bug，但關於項目的來龍去脈始終雲里霧裡。對於as ...
學習asp.net 已經有近三個月的時間了，在asp.net mvc上花的時間最多，但個人真是有些菜，不得不說，asp.net mvc的水真的還是蠻深的。目前在公司實習，也見過公司幾個項目的代碼了。對項目的代碼始終停留在一知半解的地步，能改一些簡單的bug，但關於項目的來龍去脈始終雲里霧裡。對於asp.net mvc的架構始終看不懂。因此，照著傳智博客的學習視頻，學了一下簡單的架構搭建。真個架構的搭建我看了將近兩遍視頻，才稍稍有些頭緒，今天在這裡記錄一下，一方面加深理解，一方面如果以後忘記了，還能快速的想起來，當然如果我的這篇簡陋的隨筆能有幸被有需要的人看見，並對他們產生一些幫助，我心裡肯定也是非常歡欣的。
好了，閑言少敘，那我就開始寫了。
本篇博客我主要想講如何使用 asp.net mvc + EF + spring.net 搭建一個簡單的項目框架，我也並不是對前前後後所有的內容都理解，有的地方是囫圇吞棗，水平太菜，見諒。
在開始搭框架之前，先做一些準備工作：
（1）新建解決方案：
新建一個解決方案，然後在解決方案下間五個文件夾，分別為 Common、Bll、Dal、Model、UI.如下圖所示：
（說明:我的項目命名為IotPf.Proj，因為之前做過一個物聯網雲平臺的項目，這裡打算用.net重做實踐一下，練練手）
（2）在Model層中新建類庫 Model,然後添加EF資料庫實體
添加實體的操作我就不啰嗦了，我以前的博客有講到。結果如下：
（3）分別在Bll里新建類庫 XXX.Bll 和 XXX.IBll,在Dal里新建XXX.Dal和XXX.IDal,如圖所示：
（4）在UI下麵新建應用程式IotPf.UI
好了，準備工作已經做好了，下麵進入正題。
1.首先在IofPf.Dal中新建UsersDal.cs文件，這個裡面寫對於User表的增刪改查等系列資料庫操作。如下入圖所示：
下麵列出在UserDal中寫的關於增刪改查幾個最常用操作的最基本寫法，然後對其進行調用（當然只是那種最簡單的調用，不涉及如和進行解耦的操作）：
看代碼：
1 public class UserDal
2 {
3 IotPfModel context = new IotPfModel();
4 //使用lambda表示式查詢
5 public IQueryable<Users> GetUsersByLambda(Expression<Func<Users,bool>> wherelambda)
6 {
7 return context.Users.Where(wherelambda).AsQueryable();
8
9 }
10
11 //分頁查詢
12 #region 增刪改
13 public Users AddUser(Users user)
14 {
15 context.Users.Add(user);
16 context.SaveChanges();
17 return user;
18 }
19
20 public bool DeleteUser(Users user)
21 {
22 context.Entry(user).State = System.Data.Entity.EntityState.Deleted;
23 return context.SaveChanges() > 0;
24 }
25
26 public bool UpdateUser(Users user)
27 {
28 context.Entry(user).State = System.Data.Entity.EntityState.Modified;
29 return context.SaveChanges() > 0;
30 }
31 #endregion
32 }
UserDal
上面的代碼寫了增刪改查四個方法，其中查詢的方法是根據lambda表達式自定義查詢條件。
上面的代存在一下幾個方面的問題：（以很通俗化的語言描述，不寫菜鳥看不懂的話）
（1）首先，UserDal中對資料庫進行操作首先要做的就是實例化上下文。目前，我們使用的是單一的EF操作資料庫，所以實例化的就是EF的上下文，但是，操作數據的方式不止EF這一種，如果有一天我們的項目突然要求要用NH（另一種操作資料庫的方式，但我沒學過）操作資料庫，那麼如果我們像這樣寫的話，麻煩就大了。我們的項目肯定不會只有一個XXXDal，有很多個的，如果上下文變了，那我們就要改好多個XXXDal里的代碼，這就牽一發而動全身了，相當麻煩，這就是第一個問題。
解決方法：可以把實例化上下文的操作單獨的放在一個類中，在類中定義一個 GetDalContext()的方法，然後所有的XXXDal都可以調用這個方法，如果上下文變了，那麼只需要改這一個文件就可以了，這就靈活一些了。
具體做法：
在IotPf.Dal中新建DbContextFactory.cs文件，然後編寫代碼如下：
1 public class DbContextFactory
2 {
3 public static DbContext GetCurrentDbContext()
4 {
5 return new IotPfModel();
6 }
7 }
優化後的寫法如下：
1 public static DbContext GetCurrentDbContext()
2 {
3 DbContext context = CallContext.GetData("DbContext") as DbContext;
4 if (context == null)
5 {
6 context = new IotPfModel();
7 CallContext.SetData("DbContext", context);
8 }
9
10 return context;
11}
（別問我為啥這麼優化，尷尬的告訴你，本菜雞不知道啊！）
（2）其次，UserDal中的這幾個方法是最最常用的方法，幾乎每個XXXDal中都會用到這四個方法，那我們就在每個XXXDal中都寫一遍嗎？這顯然是不合理的，這是無用功；
解決方法：常用的公共的方法，可以封裝到一個基類中，所有需要用到的類都繼承這個基類就可以了；
具體做法：
在IotPf.Dal下新建一個BaseDal.cs，然後編輯代碼如下：
1 public class BaseDal<T> where T : class ,new()
2 {
3 //實例化上下文
4 DbContext context = DbContextFactory.GetCurrentDbContext();
5 //使用lambda條件進行查詢
6 public IQueryable<T> GetEntityByLambda(Expression<Func<T,bool>> wherelambda)
7 {
8 return context.Set<T>().Where(wherelambda).AsQueryable();
9 }
10
11 //增刪改
12 #region 增刪改
13 public T AddEntity(T entity)
14 {
15 context.Set<T>().Add(entity);
16 context.SaveChanges();
17 return entity;
18 }
19 public bool DeleteEntity(T entity)
20 {
21 context.Entry<T>(entity).State = EntityState.Deleted;
22 return context.SaveChanges() > 0;
23 }
24 public bool UpdateEntity(T entity)
25 {
26 context.Entry<T>(entity).State = EntityState.Modified;
27 return context.SaveChanges() > 0;
28 }
29 #endregion
30 }
然後，在UserDal中的代碼就可以註釋掉了，直接讓UserDal繼承BaseDal就可以了，其他的XXXDal也是如此：
1 public class UserDal:BaseDal<Users>
2.在IofPf.Bll中編寫業務邏輯層代碼
在業務邏輯層中新建UserService.cs文件，然後書寫一個添加數據的方法：
public class UserService
{
UserDal userDal = new UserDal();//這個地方問題嚴重
public Users AddUser(Users user)
{
userDal.AddEntity(user);
return user;
}
}
好了，問題又來了，又到了一個要解耦的地方。
UserDal userDal = new UserDal();//這個地方問題嚴重
著重要講的是這一句：
（1）首先，Bll層（UserService）中直接用了Dal層中的類（UserDal），這使得兩層之間的聯繫很緊，耦合度太高，只要UserDal有任何變化，那麼Bll層就要進行相應的改動。
改進1：在Dal層和Bll層之間添加介面層IDal,以後調用XXXDal的時候，使用IXXXDal進行調用，這樣就用介面層把兩個層隔離開來了：
具體做法：
在IotPf.IDal下新建介面文件IUserDal.cs,然後讓UserDal繼承IUserDal,當然，BaseDal的介面也是同理，下麵給出代碼如下：
IBaseDal:
1 public interface IBaseDal<T> where T : class,new()
2 {
3 IQueryable<T> GetEntityByLambda(Expression<Func<T, bool>> wherelambda);
4
5 T AddEntity(T entity);
6
7 bool DeleteEntity(T entity);
8
9 bool UpdateEntity(T entity);
10 }
IUserDal:
public interface IUserDal:IBaseDal<Users>
{
}
UserDal和BaseDal都要繼承IUserDal和IBaseDal才行哦，不然調不動的呢。
使用介面後則調用過程變為這樣：
IUserDal userDal = new UserDal();
其實像這樣寫問題仍然蠻嚴重的。為啥呢？且看第二個問題：
（2）我們肯定不止一個文件會用到UserDal吧，實際上很多個文件都會用到UserDal。但是，如果有一天，我的Dal要由EF寫的UserDal換為NH寫的NHUserDal,那可怎麼整呢，我難道要在每個用到UserDal的文件里分別去把new UserDal() 換為 new NHUserDal()?,顯然不啊，和上面那個上下文的類似，我們新建一個類，把new UserDal的操作單獨取出來，放在一個單獨的方法中，這樣只需要改一個地方就可以了。
具體做法：
在IotPf.Factory下新建AbstractFactory.cs,然後在裡面添加如下代碼：
1 public class AbstractFactory
2 {
3 public static IUserDal GetCurrentUserDal()
4 {
5 return new UserDal();
6 }
7 }
然後調用過程進一步改進為如下：
IUserDal userDal = AbstractFactory.GetCurrentUserDal();
這樣就要靈活多了。
這種做法其實就是工廠的概念啦。
但是，這樣仍然不完美的啦，是不是很惱火，怎麼這麼麻煩，還能不能愉快的寫代碼了。哈哈哈，莫慌，麻煩是麻煩，但這種思想還是很牛逼的，好處多多哇。下麵看問題：
（3）我接下來說 AbstractFactory.cs裡面的不足之處。什麼不足之處呢？
現在我只寫了一個GetCurrentUserDal() 對吧，這改起來倒是方便了，但是做項目不可能只有一個UserDal啊，以後肯定會有 ADal啊，BDal,CDal等各種Dal,一旦EF變為NH，那在這個工廠里不是又要改一堆名字了嗎？這也太煩了啊。那怎麼弄呢？看下麵：
我們可以把所使用的資料庫操作方式（EF還是NH還是Ado.net）寫進一個配置文件裡面。假設我現在有兩種方式操作資料庫，EF和NH，一種操作資料庫的方法寫在項目EFDal下，另一種寫在NHDal項目下，然後讓兩個項目下各個操作方法的名字保持一致。如果要用EF操作，那就在配置文件中引用 EFDal，如果用NH操作，那就在配置文件中引用NHDal,這樣就可以切換自如了，是不是很方便呢，哈哈，確實挺溜的呀。
具體做法：
首先，在Ui下的web.config文件中此處添加如下代碼：
代碼：
<add key="DalAssemblyName" value="IotPf.Dal"/>
然後在 AbstractFactory.cs下添加如下代碼：
//配置文件設置
public static string AssemblyName = System.Configuration.ConfigurationManager.AppSettings["DalAssemblyName"];
public static IUserDal GetUserDal()
{
//配置文件設置 ,移到方法外面，會被多個GetXXXDal使用
// string AssemblyName = System.Configuration.ConfigurationManager.AppSettings["DalAssemblyName"];
return Assembly.Load(AssemblyName).CreateInstance(AssemblyName + ".UserDal") as IUserDal;
}
這裡因為使用了配置文件，所以不要忘記添加下麵這個引用哦：
這就是所謂的 抽象工廠的概念啦。
就像我現在用的是IotPf.Dal，那我在配置文件里的value那個地方就寫IotPf.Dal,以後如果我需要用IotPf.XXXDal，那我就把value改為IotPf.XXXDal就好了。
3.下麵我們來講一下DbSession
DbSession是啥呢？說起DbSession那就要從上面的UserService接著講啦。下麵要說一下 上下文的 context.SaveChanges()了。
我們應該都知道的，如果我們操作上下文對資料庫進行了 增、刪、改的操作，那麼操作結束後需要有一個 context.SaveChanges()的操作,用來把對實體的修改保存到資料庫中。目前，我們這個操作是寫在UserDal中的。但是，這樣做有一個問題，什麼問題呢，我們先看一下下麵這段代碼：
1 IUserDal userDal = AbstractFactory.GetUserDal();
2 public Users AddUser(Users user)
3 {
4 userDal.AddEntity(user);
5 userDal.DeleteEntity(user);
6 userDal.UpdateEntity(user);
7 return user;
8 }
這段代碼中調用了三個UserDal中的方法，分別對資料庫進行了三次不同的操作，每次操作之後相應的都會執行一次context.SaveChanges()的操作，也就是說與資料庫交互了三次。有沒有覺得三次有點多了呢，明明可以更少的呀，以後如果代碼量大了，可能會交互更多次，那性能就很差了呀。這裡呀，我們明明可以只交互一次就搞定的呀，怎麼做呢，我們可以在把SaveChanges()的操作從UserDal中遷移到UserService中的呀，在UserDal中的每個方法先不寫context.SaveChanges（）的操作，而是在UserService中把增刪改這單個操作一起完成之後再統一進行提交，那豈不是更好嗎。就像下麵這樣：
（此代碼僅說明統一提交的意思，不是實際程式中的寫法，看這個的同學不要粘這段代碼）
1 IUserDal userDal = AbstractFactory.GetUserDal();
2 public Users AddUser(Users user)
3 {
4 userDal.AddEntity(user);
5 userDal.DeleteEntity(user);
6 userDal.UpdateEntity(user);
context.SaveChanges();//統一提交
7 return user;
8 }
下麵具體來講做法：
首先，在IotPf.Factory下新建類 DbSession.cs,然後在裡面編寫如下代碼：
1 public class DbSession
2 {
3 //聲明UserDal
4 public IUserDal UserDal
5 {
6 get
7 {
8 return AbstractFactory.GetUserDal();
9 }
10 }
11 //保存實體
12 public int SaveChanges()
13 {
14 return DbContextFactory.GetCurrentDbContext().SaveChanges();
15 }
16 }
看到沒，聲明UserDal的操作現在搬到DbSession中了。
然後，UserService.cs現在變成下麵這種寫法：
1 public class UserService
2 {
3
4 //IUserDal userDal = AbstractFactory.GetUserDal();
5 DbSession dbSession = new DbSession();
6 public Users AddUser(Users user)
7 {
8 dbSession.UserDal.AddEntity(user);
9 dbSession.UserDal.DeleteEntity(user);
10 dbSession.UserDal.UpdateEntity(user);
11 dbSession.SaveChanges();
12 return user;
13 }
14 }
保存操作已經不再由Dal層控制了，而是提交到Bll層，由Bll層控制。當然，不要忘記回到Dal層，把原來代碼中的SaveChanges操作去掉：去掉後代碼如下：
1 public class BaseDal<T> where T : class , new()
2 {
3 //實例化上下文
4 DbContext context = DbContextFactory.GetCurrentDbContext();
5 //使用lambda條件進行查詢
6 public IQueryable<T> GetEntityByLambda(Expression<Func<T,bool>> wherelambda)
7 {
8 return context.Set<T>().Where(wherelambda).AsQueryable();
9 }
10
11 //增刪改
12 #region 增刪改
13 public T AddEntity(T entity)
14 {
15 context.Set<T>().Add(entity);
16 // context.SaveChanges();
17 return entity;
18 }
19 public bool DeleteEntity(T entity)
20 {
21 context.Entry<T>(entity).State = EntityState.Deleted;
22 // return context.SaveChanges() > 0;
23 return true;
24 }
25 public bool UpdateEntity(T entity)
26 {
27 context.Entry<T>(entity).State = EntityState.Modified;
28 // return context.SaveChanges() > 0;
29 return true;
30 }
31 #endregion
32 }
現在是不是就好多了，以後與資料庫交互的次數就大大減少了，這樣性能應該能提高不少吧，哈哈。
緊接著，我們需要將DbSession和Bll層進行隔離，也就是這個操作：
現在應該已經輕車熟路了，先新建介面層 IDbSession.cs ,然後新建DbSessionFactory.cs，下麵給出代碼：
IDbSession.cs
1 public interface IDbSession
2 {
3 IUserDal UserDal { get; }
4 int SaveChanges();
5 }
DbSessionFactory.cs:
1 public static IDbSession GetCurrentDbSession()
2 {
3 IDbSession dbSession = CallContext.GetData("DbSession") as IDbSession;
4 if (dbSession == null)
5 {
6 dbSession = new DbSession();
7 CallContext.SetData("DbSession", dbSession);
8 }
9 return dbSession;
10 }
現在UserService.cs中的代碼就變成這樣：
1 IDbSession dbSession = DbSessionFactory.GetCurrentDbSession();
2 public Users AddUser(Users user)
3 {
4 dbSession.UserDal.AddEntity(user);
5 dbSession.UserDal.DeleteEntity(user);
6 dbSession.UserDal.UpdateEntity(user);
7 dbSession.SaveChanges();
8 return user;
9 }
寫到這裡，數據訪問層Dal和業務邏輯成Bll之間的解耦基本已經說完了，我感覺應該還是講的比較清楚的了哈。
這個框架搭建的前半部分就已經講完了，後面關於業務邏輯層Bll和展示層UI之間的系列操作，我留到下一篇講啦，哈哈，一下子寫完我自己hold不住，你估計也看不下去了吧。
下麵總結一下哈：
本篇內容扯了那麼長，我也真是夠有尿性的了，總結起來其實也就幾個內容而已啦：
（1）使用介面層進行層與層之間的隔離；
（2）對重覆多次使用的方法進行基類封裝；
（3）使用工廠的概念，對資料庫操作方法進行配置，便於應對資料庫的更換，提高框架靈活性；
（4）使用DbSession將資料庫保存操作的許可權有Dal層提交到業務邏輯層，減少與資料庫交互次數，提高代碼性能；
下一篇將介紹spring.net的使用，雖然我自己也不咋會 ，但還是把自己理解的寫出來吧，以寫代練，加深理解，大神們不要見笑啊。
我的eMail:[email protected]
完成框架代碼就不往上貼了哈，有需要的同學可以給我發郵件索取。
明天就是國慶節啦，提前祝大家國慶節快樂，祝祖國繁榮昌盛！
