『飛秋』關于ASP.NET MVC+Repository+Service架構的一些思考

看了一些ASP.NET MVC開源項目后的一些想法，關于ASP.NET MVC+Repository+Service架構的一些思考
最近在學習ASP.NET MVC 2.0的一些開源項目，發現這些項目中都普遍用到了同一種架構設計，即：

ASP.NET MVC + Service + Repository。從網上看了一些關于這方面的介紹后覺得這種架構確實滿好的。以微軟的一個典型的開源項目Oxite為例：

該項目由下面的Projects組成：

1）Oxite;

2）Oxite.LinqtoSqlDataProvider;

3）Oxite.Mvc;

4）Oxite.Mvc.Tests;

5）OxiteSite；

?

Oxite Project：

1）定義所有項目中需要用到的Model，即Entity，并且所有的Model都是純Model，它們不依賴于任何ORM框架相關的信息。Model的作用是作為數據在UI層、業務邏輯層、數據訪問層之間傳遞；

2）定義Repository接口。Repository和通常三層架構中的數據庫訪問層（DAL）從形式和功能上看差不多，個人感覺區別兩者在意圖上有所不同。
Repository是DDD（Domain-Driven Design 領域驅動模型 ）中的概念，強調Repository是受Domain驅動的，Repository中定義的功能要體現Domain的意圖和約束，而DAL更純粹的就是提供數據訪問的功能，并不嚴格受限于Business層。Repository所提供的一切接口都應該是業務邏輯層所需要的，如果業務邏輯不需要的，它就不必提供。但是最近看到網上有一些朋友實現了一些泛型的Repository接口，個人認為不是很好。因為這違背了我們設計Repository的初衷，Repository接口是提供給Domain層的操作契約，不同的Entity對于Domain來說可能有不同的操作約束，比如User可能不應該被刪除，BookOrder可能不應該被修改，也就是說Domain層根本就不應該能調用_repository<User>.Delete(user)，_repository<BookOrder>.Update(BookOrder)這樣的操作。因此，Repository接口還是應該單獨針對每個Entity類來定義。

3）定義和實現Service層。

Servide層定義和實現了整個應用程序的所有業務邏輯。Service利用Repository接口來完成數據庫操作。每個Service接口除了利用Repository來操作數據庫之外，還會做很多額外的事情，如數據驗證等。

?

Oxite.LinqtoSqlDataProvider Project：

該項目是用 Linq to Sql ORM 技術實現的一個具體的 DataProvider（Repository）。該項目中會定義一些Linq to Sql ORM框架相關的Entities，借助于LINQ強大的語法功能，我們可以很方便的把這些Entities轉換為Oxite中定義的Entity。如：

?1 public User GetUser(string name)
?2 {
?3???? return (from u in context.oxite_Users
?4???????????? where string.Compare(u.Username, name, true) == 0
?5???????????? select new User()
?6???????????? {
?7???????????????? ID = u.UserID,
?8???????????????? Name = u.Username,
?9???????????????? DisplayName = u.DisplayName,
10???????????????? Email = u.Email,
11???????????????? HashedEmail = u.HashedEmail,
12???????????????? Password = u.Password,
13???????????????? PasswordSalt = u.PasswordSalt,
14???????????????? Status = u.Status
15???????????? }).FirstOrDefault();
16 }
?

?

oxite_User是Linq to Sql ORM框架所生成的Entity，User就是Oxite Model中定義的Entity。

?

Oxite.Mvc Project：

該項目包含了所有的Controller，但不包含View；Controller負責利用Service層來為View提供服務。一般來說，只要是和ASP.NET MVC相關的技術，都不應該放在Service層中實現，而應該放在Controller中實現。這樣可以確保Service層可以被非ASP.NET MVC技術的程序所重用。

?

OxiteSite Project：

該項目就是一個普通的ASP.NET MVC Website，但它僅僅包含了一些View以及js和css等。

?

總結：

上面的架構設計我覺得有以下三個好處：

1）Oxite project實際上已經完整的代表了的應用了。因為一個應用由UI、Business、Data三部分組成。而這個project包含了Business和Data，當然，應該說它包含了對整個應用程序的業務邏輯的描述，并沒有包含具體的業務邏輯實現，具體的業務邏輯的數據持久化實現是通過Oxite.LinqtoSqlDataProvider這個項目實現的。但這并不影響我們把Oxite理解為整個應用的主體。所以我想這個項目就是ASP.NET MVC架構中的Model吧。

2）利用Repository模式，完全把應用程序的業務邏輯和數據持久化工作分離。所以我們完全可以編寫很多不同的ORM框架來完成數據的持久化工作。我們唯一需要配置的就是在web.config文件中設置該使用哪一個DataProvider；當然，就Oxite這個開源項目而言，在Oxite.LinqtoSqlDataProvider中單獨定義了另外一套Entity，導致我們在查詢數據時必須要做一個Entity的轉換。這一點也許是我覺得有點不好的地方吧。當然其實Linq to Sql是支持xml來配置ORM映射關系的。所以理論上應該支持不用另外定義一套Entity。

3）前臺利用ASP.NET MVC技術實現，并且把Controller和View分離在不同的項目中實現。個人覺得主要的考慮是為了更好的團隊開發。讓開發View的人專注于設計View，而讓Controller開發人員專注于View和Model之間的控制協調。

?

所以，可以設想，如果基于這樣的架構開發一個應用，個人覺得可以先開發好Model，然后再開發一個或幾個DataProvider來實現Model中定義的Business，然后可以寫一個Test工程來測試這個Model，等Model穩定后，再去開發View和Controller。

?

以上是我對我最近看的一些ASP.NET MVC開源項目的一點小小的思考，歡迎大家批評指正。
飛秋官網：http://www.freeeim.com/

總結

以上是生活随笔為你收集整理的『飞秋』关于ASP.NET MVC+Repository+Service架构的一些思考的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。