最近在學(xué)習(xí)ASP.NET MVC 2.0的一些開源項(xiàng)目，發(fā)現(xiàn)這些項(xiàng)目中都普遍用到了同一種架構(gòu)設(shè)計(jì)，即：

ASP.NET MVC + Service + Repository。從網(wǎng)上看了一些關(guān)于這方面的介紹后覺得這種架構(gòu)確實(shí)滿好的。以微軟的一個(gè)典型的開源項(xiàng)目Oxite為例：

該項(xiàng)目由下面的Projects組成：

1）Oxite;

2）Oxite.LinqtoSqlDataProvider;

3）Oxite.Mvc;

4）Oxite.Mvc.Tests;

5）OxiteSite；

Oxite Project：

1. 定義所有項(xiàng)目中需要用到的Model，即Entity，并且所有的Model都是純Model，它們不依賴于任何ORM框架相關(guān)的信息。Model的作用是作為數(shù)據(jù)在UI層、業(yè)務(wù)邏輯層、數(shù)據(jù)訪問層之間傳遞；
2. 定義Repository接口。Repository和通常三層架構(gòu)中的數(shù)據(jù)庫訪問層（DAL）從形式和功能上看差不多，個(gè)人感覺區(qū)別兩者在意圖上有所不同。Repository是DDD（Domain-Driven Design?領(lǐng)域驅(qū)動(dòng)模型?）中的概念，強(qiáng)調(diào)Repository是受Domain驅(qū)動(dòng)的，Repository中定義的功能要體現(xiàn)Domain的意圖和約束，而DAL更純粹的就是提供數(shù)據(jù)訪問的功能，并不嚴(yán)格受限于Business層。Repository所提供的一切接口都應(yīng)該是業(yè)務(wù)邏輯層所需要的，如果業(yè)務(wù)邏輯不需要的，它就不必提供。但是最近看到網(wǎng)上有一些朋友實(shí)現(xiàn)了一些泛型的Repository接口，個(gè)人認(rèn)為不是很好。因?yàn)檫@違背了我們?cè)O(shè)計(jì)Repository的初衷，Repository接口是提供給Domain層的操作契約，不同的Entity對(duì)于Domain來說可能有不同的操作約束，比如User可能不應(yīng)該被刪除，BookOrder可能不應(yīng)該被修改，也就是說Domain層根本就不應(yīng)該能調(diào)用_repository<User>.Delete(user)，_repository<BookOrder>.Update(BookOrder)這樣的操作。因此，Repository接口還是應(yīng)該單獨(dú)針對(duì)每個(gè)Entity類來定義。
3. 定義和實(shí)現(xiàn)Service層。Servide層定義和實(shí)現(xiàn)了整個(gè)應(yīng)用程序的所有業(yè)務(wù)邏輯。Service利用Repository接口來完成數(shù)據(jù)庫操作。每個(gè)Service接口除了利用Repository來操作數(shù)據(jù)庫之外，還會(huì)做很多額外的事情，如數(shù)據(jù)驗(yàn)證等。

Oxite.LinqtoSqlDataProvider Project：

該項(xiàng)目是用 Linq to Sql ORM 技術(shù)實(shí)現(xiàn)的一個(gè)具體的 DataProvider（Repository）。該項(xiàng)目中會(huì)定義一些Linq to Sql ORM框架相關(guān)的Entities，借助于LINQ強(qiáng)大的語法功能，我們可以很方便的把這些Entities轉(zhuǎn)換為Oxite中定義的Entity。如：

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

Oxite.Mvc Project：

該項(xiàng)目包含了所有的Controller，但不包含View；Controller負(fù)責(zé)利用Service層來為View提供服務(wù)。一般來說，只要是和ASP.NET MVC相關(guān)的技術(shù)，都不應(yīng)該放在Service層中實(shí)現(xiàn)，而應(yīng)該放在Controller中實(shí)現(xiàn)。這樣可以確保Service層可以被非ASP.NET MVC技術(shù)的程序所重用。

OxiteSite Project：

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

?

總結(jié)：

上面的架構(gòu)設(shè)計(jì)我覺得有以下三個(gè)好處：

1. Oxite project實(shí)際上已經(jīng)完整的代表了的應(yīng)用了。因?yàn)橐粋€(gè)應(yīng)用由UI、Business、Data三部分組成。而這個(gè)project包含了Business和Data，當(dāng)然，應(yīng)該說它包含了對(duì)整個(gè)應(yīng)用程序的業(yè)務(wù)邏輯的描述，并沒有包含具體的業(yè)務(wù)邏輯實(shí)現(xiàn)，具體的業(yè)務(wù)邏輯的數(shù)據(jù)持久化實(shí)現(xiàn)是通過Oxite.LinqtoSqlDataProvider這個(gè)項(xiàng)目實(shí)現(xiàn)的。但這并不影響我們把Oxite理解為整個(gè)應(yīng)用的主體。所以我想這個(gè)項(xiàng)目就是ASP.NET MVC架構(gòu)中的Model吧。
2. 利用Repository模式，完全把應(yīng)用程序的業(yè)務(wù)邏輯和數(shù)據(jù)持久化工作分離。所以我們完全可以編寫很多不同的ORM框架來完成數(shù)據(jù)的持久化工作。我們唯一需要配置的就是在web.config文件中設(shè)置該使用哪一個(gè)DataProvider；當(dāng)然，就Oxite這個(gè)開源項(xiàng)目而言，在Oxite.LinqtoSqlDataProvider中單獨(dú)定義了另外一套Entity，導(dǎo)致我們?cè)诓樵償?shù)據(jù)時(shí)必須要做一個(gè)Entity的轉(zhuǎn)換。這一點(diǎn)也許是我覺得有點(diǎn)不好的地方吧。當(dāng)然其實(shí)Linq to Sql是支持xml來配置ORM映射關(guān)系的。所以理論上應(yīng)該支持不用另外定義一套Entity。
3. 前臺(tái)利用ASP.NET MVC技術(shù)實(shí)現(xiàn)，并且把Controller和View分離在不同的項(xiàng)目中實(shí)現(xiàn)。個(gè)人覺得主要的考慮是為了更好的團(tuán)隊(duì)開發(fā)。讓開發(fā)View的人專注于設(shè)計(jì)View，而讓Controller開發(fā)人員專注于View和Model之間的控制協(xié)調(diào)。

所以，可以設(shè)想，如果基于這樣的架構(gòu)開發(fā)一個(gè)應(yīng)用，個(gè)人覺得可以先開發(fā)好Model，然后再開發(fā)一個(gè)或幾個(gè)DataProvider來實(shí)現(xiàn)Model中定義的Business，然后可以寫一個(gè)Test工程來測(cè)試這個(gè)Model，等Model穩(wěn)定后，再去開發(fā)View和Controller。

以上是我對(duì)我最近看的一些ASP.NET MVC開源項(xiàng)目的一點(diǎn)小小的思考，歡迎大家批評(píng)指正。

微軟的一個(gè)開源項(xiàng)目Oxite學(xué)習(xí)后的感受