|
在ASP.NET中實現(xiàn)Model-View-Controller模式（五）
測試
將模型部分從ASP.NET環(huán)境中分離出來能夠使模型部分更容易的被測試。在ASP.NET環(huán)境中進(jìn)行測試的話，你必須同時測試很多方面，如HTML代碼是否正確，而讀取HTML代碼的工作是非常煩悶的。將模型部分分離出來，使你能夠?qū)δＰ筒糠肿鰡为?dú)的單元測試。下面是NUnit (http://nunit.org)對模型部分進(jìn)行單元測試的例子。
using System;
using NUnit.Framework;
using System.Collections;
using System.Data;
using System.Data.SqlClient;
[TestFixture]
public class GatewayFixture
{
[Test]
public void Tracks1234Query()
{
DataSet ds = DatabaseGateway.GetTracks("1234");
Assertion.AssertEquals(10, ds.Tables["Track"].Rows.Count);
}
[Test]
public void Tracks2345Query()
{
DataSet ds = DatabaseGateway.GetTracks("2345");
Assertion.AssertEquals(3, ds.Tables["Track"].Rows.Count);
}
[Test]
public void Recordings()
{
DataSet ds = DatabaseGateway.GetRecordings();
Assertion.AssertEquals(4, ds.Tables["Recording"].Rows.Count);
DataTable recording = ds.Tables["Recording"];
Assertion.AssertEquals(4, recording.Rows.Count);
DataRow firstRow = recording.Rows[0];
string title = (string)firstRow["title"];
Assertion.AssertEquals("Up", title.Trim());
}
}
結(jié)論：
在ASP.NET中實現(xiàn)MVC模式有如下優(yōu)缺點：
優(yōu)勢：
能夠減少依賴。 程序員可以在一個ASP.NET頁面中實現(xiàn)所有的代碼。單頁的實現(xiàn)方式，對于一些小型的且生存周期不長的程序是適用的。但如果想在不斷增加的頁面間共享代碼的話，將代碼的不同部分進(jìn)行分離是非常有效果的。
能夠減少代碼的復(fù)制。 DatabaseGateway 類中的GetRecordings 和 GetTracks方法能夠直接被其它的頁面使用，減少了必須將方法的代碼拷貝到不同頁面的情況。
能夠把不同人員的責(zé)任分開。修改頁面的外觀與修改數(shù)據(jù)訪問的代碼所用的技術(shù)是不同的，將模型與視圖分開能夠使負(fù)責(zé)不同工作的專家協(xié)同的工作。
使性能優(yōu)化的成為可能 按將系統(tǒng)不同的職責(zé)分成不同的類，使性能的優(yōu)化成為可能。前面的例子中，由于每次請求頁面的時都要從數(shù)據(jù)庫中讀取數(shù)據(jù)。因此可在某種情況下將數(shù)據(jù)緩存，從而提高整個程序的性能。如果不將代碼進(jìn)行分離的話是無法做到的這點的。
易測試性 將模型與視圖相分離使在ASP.NET環(huán)境外進(jìn)行單元測試成為可能。
缺點：
增加了代碼的數(shù)量及復(fù)雜度。這個例子在早期單頁的實現(xiàn)方式的基礎(chǔ)上增加了新的文件和代碼，在無形中增加了維護(hù)的開銷。一旦修改系統(tǒng)的話，會修改所有三種角色的代碼。在一些情況下，一個文件中的修改比一些文件中修改要方便。所以在考慮是否使用MVC模式時。這種額外的開銷一定要被計算在內(nèi)，對一些小的程序來說，這種開銷是不值得的。
|
