最近在學習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：
- 定義所有項目中需要用到的Model，即Entity，并且所有的Model都是純Model，它們不依賴于任何ORM框架相關的信息。Model的作用是作為數據在UI層、業務邏輯層、數據訪問層之間傳遞；
- 定義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類來定義。
- 定義和實現Service層。Servide層定義和實現了整個應用程序的所有業務邏輯。Service利用Repository接口來完成數據庫操作。每個Service接口除了利用Repository來操作數據庫之外，還會做很多額外的事情，如數據驗證等。
Oxite.LinqtoSqlDataProvider Project：
該項目是用 Linq to Sql ORM 技術實現的一個具體的 DataProvider（Repository）。該項目中會定義一些Linq to Sql ORM框架相關的Entities，借助于LINQ強大的語法功能，我們可以很方便的把這些Entities轉換為Oxite中定義的Entity。如：
?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等。
?
總結：
上面的架構設計我覺得有以下三個好處：
- Oxite project實際上已經完整的代表了的應用了。因為一個應用由UI、Business、Data三部分組成。而這個project包含了Business和Data，當然，應該說它包含了對整個應用程序的業務邏輯的描述，并沒有包含具體的業務邏輯實現，具體的業務邏輯的數據持久化實現是通過Oxite.LinqtoSqlDataProvider這個項目實現的。但這并不影響我們把Oxite理解為整個應用的主體。所以我想這個項目就是ASP.NET MVC架構中的Model吧。
- 利用Repository模式，完全把應用程序的業務邏輯和數據持久化工作分離。所以我們完全可以編寫很多不同的ORM框架來完成數據的持久化工作。我們唯一需要配置的就是在web.config文件中設置該使用哪一個DataProvider；當然，就Oxite這個開源項目而言，在Oxite.LinqtoSqlDataProvider中單獨定義了另外一套Entity，導致我們在查詢數據時必須要做一個Entity的轉換。這一點也許是我覺得有點不好的地方吧。當然其實Linq to Sql是支持xml來配置ORM映射關系的。所以理論上應該支持不用另外定義一套Entity。
- 前臺利用ASP.NET MVC技術實現，并且把Controller和View分離在不同的項目中實現。個人覺得主要的考慮是為了更好的團隊開發。讓開發View的人專注于設計View，而讓Controller開發人員專注于View和Model之間的控制協調。
所以，可以設想，如果基于這樣的架構開發一個應用，個人覺得可以先開發好Model，然后再開發一個或幾個DataProvider來實現Model中定義的Business，然后可以寫一個Test工程來測試這個Model，等Model穩定后，再去開發View和Controller。
以上是我對我最近看的一些ASP.NET MVC開源項目的一點小小的思考，歡迎大家批評指正。
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
