看了一些ASP.NET MVC開源項目後的一些想法，關於ASP.NET MVC+Repository+Service架構的一些思考

原文地址：http://www.cnblogs.com/netfocus/archive/2010/08/01/1790048.html

 

最近在學習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開源項目的一點小小的思考，歡迎大家批評指正。