基於ASP.NET MVC架構開發Web論壇應用程式

我想通過本系列文章從頭到尾構建一個完整的ASP.NET MVC論壇應用程式，最終的目的是探討和推動使用ASP.NET MVC架構構建應用程式的最佳實務。

      1、 簡介

在本篇中，我想先從全域方面介紹一下論壇應用程式的總體目標。在本篇中，我將討論一下避免代碼壞味道的重要性，還將討論如何利用軟體設計原則和模式來協助你編寫適合未來改變的富有彈性的代碼。最後，我還將論證一下為什麼我選擇使用測試驅動開發方式構建本系列文章中的論壇應用程式。

      2、 什麼樣的軟體是好的軟體

我不想僅僅為了構建論壇應用程式而任意構建此論壇應用程式。我的目標是儘可能構建最棒的論壇應用程式。
    這個目標立即引發這樣一個問題：什麼樣的軟體是好的軟體？是什麼導致一個應用程式比另一個應用程式更好一些或更差一些呢？在事先沒有一個關於“好軟體”的定義之前，我無法聲明我構建了一個完美的論壇應用程式。
    因此，下面是我對於“好軟體”的定義。

      3、 好軟體是設計得易於修改的軟體

     存在多種原因可能需要你改變軟體：
      1)你可能需要在一個現有軟體上添加新的特徵
      2)你可能需要修改一個現有軟體中的錯誤
      3)你可能需要最佳化現有軟體
      4)你可能需要改進現有軟體的設計

      一般說來，設計糟糕的軟體是難於改變的。有些軟體設計得如此糟糕，以致於每個人都害怕碰一碰它。我們大家應該都使用過設計得糟糕的軟體。當軟體不好時，你很希望它乾脆走開；甚至如果有機會的話，你可能想從頭開始重新編寫這款軟體。

      4、 避免代碼壞味道

      Robert和Micah Martin把糟糕的軟體部分描述為代碼壞味道。下列代碼壞味道意味著此軟體的書寫是相當糟糕的：
      1)僵化性（Rigidity）—僵化的軟體是這樣的軟體，當你在某個位置作一改動時即要求對系統作出相應的一系列的更改。
      2)脆弱性（Fragility）—脆弱的軟體是這樣的軟體，你在某個位置作一改動時即打斷另外多處的正常運行。
      3)不必要的複雜性—不必要的複雜軟體是指過度設計的軟體，其目的是為了處理任何可能的改變。
      4)不必要的重複—不必要的重複軟體中包含大量的重複性代碼。
      5)晦澀性—晦澀的軟體是指難於理解的軟體。

      【注意】上述這些代碼味道在Micah和Robert Martin的著名《Agile Principles,Patterns,and Practices in C#》中得到充分的描述。在此，強烈建議讀者讀一下這本書。
    注意，上述這些代碼味道都與所有的代碼改變相關聯。每一個這些代碼味道都將妨礙代碼的改變。

      5、 軟體設計原則

      遵循良好的軟體設計原則，將有助於編寫軟體易於適應未來更改的軟體。軟體設計原則有若干，也不盡相同。例如，Cunningham和Cunningham Wiki描述物件導向設計的11個原則：
    http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign。

      其中提到的物件導向設計的前五個原則與Robert Martin及他的兒子Micah Martin編著的《Agile Principles,Patterns,and Practices in C#》中所主張的軟體設計原則是一致的。此外，Robert Martin還在Object Mentor開闢的部落格上討論了這些原則：
    http://www.objectmentor.com/resources/publishedArticles.html。

      此外，我還發現有另外兩本書中也提供了有關軟體設計原則的極其有用的資訊。第一本是Eric Freeman,Elisabeth Freeman, Kathy Sierra, Bert Bates編著的《Head First Design Patterns》；第二本是Brett McLaughlin,Gary Pollice和David West編著的《Head First Object-Oriented Analysis and Design》。儘管這些書所討論的原則與Robert Martin的提法並不十分相同，但是它們卻十分相近。

      不過真實的情況是，上述所有這些針對軟體設計原則展開討論的資源都源自Robert Martin的工作。Robert Martin並不是所有原則的發明者，但是他的確是第一個把這些原則收集到一起的人。下面列出這些軟體設計原則：
    ? SRP—單一責任原則
    ? OCP—開關原則
    ? LSP—Liskov替換原則
    ? ISP—介面隔離原則
    ? DIP—依賴倒置原則
      上述這個原則的集合正好對應於縮減詞SOLID。

      下面的軟體設計原則列表來自於《Head First Design Patterns》一書：
    ? 封裝變化
    ? 多用組合少用繼承
    ? 基於介面而不是基於實現編程
    ? 在互動的對象間努力實現松耦合
    ? 類應該為了擴充而開放，但是為了修改而關閉
    ? 依賴於抽象，而不要依賴於具體類
    ? 僅僅對你的朋友交談
    ? 不調用我，我們會調用你
    ? 一個類應該僅有一個改變的理由

 當然，上述原則之間也存在許多的重疊之處。例如，“單一責任”原則與後面的“一個類應該僅有一個改變的理由”這一原則是相一致的。然而，它們所強調的重點還是有所不同。更多的細節在此不便贅述。
  所有這些設計原則的真正動機在於，努力構建出能夠適應變化的軟體。上述原則分別對於不同的原則進行相應的闡述，最終目的也不過是為了建立出可以經得起時間測試的軟體。

    6、 軟體設計模式

    軟體設計模式描述的是應用軟體設計原則所遵循的策略的問題。換句話說，一個軟體設計原則是一個好的思想，而一個軟體設計模式是你用於實現這種好的思想的工具。

    軟體設計模式的思想最初源於書籍《Design Patterns: Elements of Reusable Object-Oriented Software》。正是這本書為其它許多描述軟體設計模式書的創作帶去靈感。

    例如，另一本書《The Head First Design Pattern》就以一種更易於理解的方式向人們介紹了GOF所著的書（即上面的那本《Design Patterns: Elements of Reusable Object-Oriented Software》）中所引入的設計模式。這本書中總共詳細介紹了下列14種軟體設計模式：
    ? Strategy
    ? Observer
    ? Decorator
    ? Factory
    ? Singleton
    ? Command
    ? Adaptor
    ? Fa?ade
    ? Template
    ? Iterator
    ? Composite
    ? State
    ? Proxy
    ? Compound

    另一本在軟體設計模式方面較有影響的書是Martin Fowler的《Patterns of Enterprise Application Architecture》。這本書還擁有一個公司網站，其中列舉了本書中所介紹的模式。此網站的網址是：http://www.martinfowler.com/eaaCatalog/。

    軟體設計模式提供給你按照模式的方式構建你的代碼，從而使之更富於適應未來的彈性修改。例如，當構建本文中的論壇應用程式時，我們就使用了一種名字為Repository的軟體設計模式進行設計。Eric Evans，在他的著作《Domain-Driven Design》中這樣描述Repository模式：

    一個REPOSITORY把某種類型的所有對象描述為一個概念的集合(通常是類比的)。其行為類似於一個集合，但是具有更細緻的支援查詢的能力。於是，符合相應類型的對象可以被添加或刪除，而位於此REPOSITORY背後的系統則可以從資料庫中添加或刪除它們。

    根據Evans的解釋，Repository模式的一個主要的優點是，它能夠協助你實現“應用程式和域設計與儲存技術，多種資料庫策略，甚至是多個資料來源之間的解耦。”換句話說，Repository模式能夠使你的應用程式免於因資料庫訪問方式的不同而重新加以改變。
    為了使我們的論壇應用程式從某一種特定的儲存技術中獨立出去，我們將在系統中引入上述Repository模式。因此，最終的此論壇應用程式的設計將能夠支援我們可以在不同的資料訪問技術（例如LINQ to SQL，Entity Framework或NHibernate）之間切換。

    7、 測試驅動開發

    我打算使用測試驅動開發原則構建本文中的MVC論壇應用程式。更具體地說是，在我編寫任何應用程式代碼之前，我將首先編寫一個應用程式代碼的單元測試。

    測試驅動開發將會基於下列原因為你帶來更高品質的代碼：
    (1)為你的代碼編寫測試能夠提供給你一個適應於未來可能改變的安全網。
    (2)為你的代碼編寫測試迫使你書寫松耦合的代碼。
    (3)在正式書寫你的代碼前為你的代碼編寫測試將迫使你從一個使用者的角度來觀察自己書寫的代碼。

    讓我們更細緻地分析上述每種特徵的優點。

    首先，單元測試提供你一個適應於未來可能改變的安全網。這是Michael Feathers在他的著作《Working Effectively with Legacy Code》一再強調的一個觀點。事實上，他把遺留代碼定義為“簡單地編碼而不進行測試”。

    當你的應用程式代碼被單元測試所覆蓋時，你可以修改該代碼而不必擔心此改動會你的代碼既有的功能。單元測試有助於使你的代碼進行更安全的重構。如果你能夠重構，那麼，你可以使用軟體設計模式修改你的代碼，這將產生更好的適應未來修改的代碼。

    其次，遵循測試驅動開發將迫使你使用一種特定的方式書寫代碼。可測試的代碼將趨於導致松耦合的代碼。單元測試能夠在各自孤立的代碼單元中執行一個測試。為了構建你的應用程式以便使之可測試，你需要使用一種可孤立的組件方式來構建應用程式。

    一個類與另一個類之間是松耦合的是指，當你改變第一個類時不必改變另一個類。測試驅動開發經常迫使你編寫松耦合的代碼，因為松耦合代碼是經得起改變的。

    最後，按照測試先行的方式書寫代碼將迫使你從一個使用者的角度來觀察自己書寫的代碼。通過首先編寫測試的方式書寫代碼，會使你站在一個未來的有可能使用你的代碼的開發人員的角度進行工作。既然編寫測試迫使你考慮另一個開發人員(也許是未來的你自己)如何使用你的代碼，那麼，你最終編寫的代碼應該是設計得更好的代碼。

    8、 莫圖眼前之利益  更宜立足於長遠

    使用測試驅動開發原則構建軟體在軟體開發之初要求開發人員付出更多的努力。儘管編寫測試需要花費一定的時間；然而，其思想是，最初構建單元測試所要求付出的努力將會在未來獲得豐厚的回報。

    存在兩種方式可以使你成為一名開發人員。你可以成長為一個牛仔，也有可能成長為一個工匠。一個牛仔能夠立即開始編碼。也就是說，一個牛仔可以以很快的速度構建一個軟體應用程式。然而，作為一個牛仔，其問題在於軟體必須要進行長期的維護。
    一個工匠則是很有忍耐性的。一個工匠總會精雕細琢地開發一款軟體。一個工匠總是非常仔細地構建單元測試，並使之涵蓋一個應用程式中所有的代碼。因此，一個工匠要花費更長的時間才能建立成功一款應用程式。然而，此應用程式在建立後，卻是易於後期的維護—更易於修改錯誤且更易於把新特徵添加到應用程式中。

    9、 總結

    總之，我們的最終目標是構建一個MVC論壇應用程式，此程式能夠經得起長時間的測試。它應該是不僅現在良好地工作，還應該在未來繼續工作—即使是當有人需要對該應用程式變更之時。
    我想利用微軟ASP.NET MVC架構開發此論壇應用程式。原因在於，這個架構可以使我更容易地編寫程式的測試代碼。而另一方面，ASP.NET MVC架構本身就從設計之初提供了對測試驅動開發的最忠誠的支援。