原文地址:Chapter 1 - An Introduction to ASP.NET MVC
“除了變化,沒有什麼是永恒的。.” -- Heraclitus
在本章中,我們為你提供了一個關於Microsoft ASP.NET MVC framework 的鳥瞰和簡介。本章的目標是向你解釋為什麼你應該使用Microsoft ASP.NET MVC 來構建你的web應用程式。
既然ASP.NET MVC
framework 的設計出發點是為了讓你寫出更好的軟體程式,本章第一部分就來討論好的應用程式應該具有的特性。你可以瞭解到軟體設計原則和模式可以協助你構建能夠適應變化的軟體。.
最後,我們討論一個ASP.NET
MVC 應用程式的架構,以及這個架構如何是你寫出更好的軟體程式。你會看到一個MVC應用程式的不同部分的概覽,包括Models、Views和Controllers,同時你也會看到關於樣本程式的介紹,這個樣本程式會在你建立一個ASP.NET
MVC項目時被建立。
A Story with a Moral
我依然記得那天,經理來到我的辦公室讓我構建一個簡單的按鈕應用程式。他解釋說需要一個簡單的撥號管理程式,當需要進行健全狀態檢查時,可以通過撥號通知相關人員,撥號管理程式會載入一個電話號碼的列表,當點擊按鈕時,程式會依次依次列表中的號碼。還有比這更簡單的嗎?
帶著自信,我鄭重其事的表示會在當天下午完成這個撥號管理程式。我關上了辦公室的們,戴上了我的牛仔帽,開啟音樂,開始狂寫代碼。在那天結束的時候,我已經完成了那個程式。我的經理很高興,我那天晚上回到家中很高興,自認為我
一天做的工作很完美。
第二天早上,我的經理又出現在我的辦公室門口。我擔心的問是不是撥號管理程式有問題,
他向我說,程式工作的很好,事實上,他是如此的喜歡以至於想再加入一個特性。他希望撥號管理程式能夠在撥打一個號碼時,現實對應的調查結果,這樣,調查結果就可以儲存到資料庫中了。
基於英雄氣概,我又一次花費了一天的時間來填充代碼。當那天結束的時候,我已經完成了對應用程式的更新,並且自豪的將完成的程式向經理進行了展示。
我不再繼續這個故事了,因為任何以構建軟體為生的人都知道這個故事的結局。故事永遠不會結束。一旦一個軟體項目開始進行,基本上很難結束它。軟體程式需要持續的填充新特性、修改bug以及提升效能等。
當你建立的一個軟體被要求進行修改時,你應該認為是一種讚美。只有沒有用處的軟體才會停滯不前的。當人們關注軟體,當軟體被頻繁的使用時,它會經曆持續的變更。
儘管我現在已經離開那家公司(我目前坐在微軟的一個辦公室中),但是我仍然有朋友在那家公司,偶爾還會收到程式變更的報告。毋庸質疑,程式已經轉變為一個龐大的應用,支援不同的時區、複雜的呼叫規則以及帶有表格的進階報表功能。它已經不能被說成是最初的簡單按鈕應用程式了。
What is Good Software?
在Web剛剛興起的時候,為了成立一個互連網新公司,我從MIT輟學。在那個年代,構建一個網站是很困難的,那時沒有ASP或者ASP.NET等技術(我們只有石刀),當時主要任務就是把以HTML格式的內容儲存到資料庫的表中,作出能閃光的文字就是很酷的事情。
當我第一次開始編寫軟體時,目標就是讓軟體去做我想讓它做得。在90年代初,競爭開始變得殘酷,在最短的時間裡添加最多的特性成為是否能夠存活下來的關鍵,為了工作,我當時經常在辦公室的桌子下面睡覺。
在我的起步階段,我定義的好的軟體具有以下特點:
好的軟體是那些可以按照你的意圖運行。
如果我感覺特別有雄心壯志,那麼我會擔心效能,同時,如果我有額外的時間,我會向代碼中追加一兩條注釋。但事實是,在一天結束的時候,我對於工作是否成功的準則很簡單:軟體是否正常工作。
在過去的八年中,我向一些大的公司和組織提供培訓和諮詢,包括Boeing, NASA, Lockheed Martin以及國家科學基金。大的組織不是新創立的公司,在一個大的組織內,焦點不在於儘可能快的構建軟體應用程式,而是在於構建能夠很容易進行維護的軟體應用程式。
多年來,我對好的軟體的定義已經在本質上發生轉變,由於我已經面對了在維護我自己的“龐然大物”的過程中帶來的可怕的情況,我對好的軟體的定義已經轉變為:
好的軟體是能夠按照你的意圖運行,並且易於修改。
有很多理由可以使得軟體隨著時間推移而發生改變。Michael Feathers,在他的著作《Working Effectively with Legacy Code》中,提供了以下理由:
1) 你可能需要在現存軟體中添加一個新的特性
2) 你可能需要修改現存軟體中的一個bug。
3) 你可能需要最佳化現有軟體。
4) 你可能需要改進現有軟體的設計。
例如,你可能需要添加一個新特性,呼叫管理應用開始時是一個簡單按鈕應用程式,然而,每天都會有越來越多的特性被加入到程式中。
在軟體中發現一個bug時,你也會需要對軟體變更。例如,在呼叫管理的程式中,我們發現對於白天時間的計算是不對的(有一些人在早上是醒著的!)。我們迅速的更改了錯誤的代碼。
你也可能需要修改軟體以使它跑的更快。有一段時間,由於商務規則變得非常複雜,呼叫管理應用程式需要花費12秒來撥打一個新電話號碼,我們不得不重寫代碼以使重新擷取電話號碼的時間縮減至毫秒級。
最後,你可能需要修改軟體來提升它的設計。換言之,你可能需要找出編寫拙劣的代碼,將其替換為良好的代碼你可能需要使你的代碼更能夠適應變化。