① ASP.NET Web應用程序與ASP.NET Web服務應用程序有什麼區別
ASP.NET
Web應用程序就是一個網站，B/S架構，客戶通過瀏覽器獲取伺服器上運行的該應用程序上的業務功能。
ASP.NET
Web服務應用程序是一個遠程服務，必須被其他網站引用才可以正常被用戶使用，相當於一個被遠程調用的方法，一般是只提供數據，不提供修改。
如我們在各個網站上的天氣預報，就是Web服務，幾個不同網站上的天氣預報功能可能共同調用的同一個Web服務源，從而表現在不同網站上被用戶看到，但Web服務本身不能直接被用戶使用。
② 基於ASP.NET MVC框架開發Web論壇應用程序
我想通過本系列文章從頭到尾構建一個完整的 MVC論壇應用程序，最終的目的是探討和推動使用 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個原則：
。
其中提到的面向對象設計的前五個原則與Robert Martin及他的兒子Micah Martin編著的《Agile Principles,Patterns,and Practices in C#》中所主張的軟體設計原則是一致的。此外，Robert Martin還在Object Mentor開辟的博客上討論了這些原則：
。
此外，我還發現有另外兩本書中也提供了有關軟體設計原則的極其有用的信息。第一本是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》。這本書還擁有一個公司網站，其中列舉了本書中所介紹的模式。此網站的網址是：。
軟體設計模式提供給你按照模式的方式構建你的代碼，從而使之更富於適應未來的彈性修改。例如，當構建本文中的論壇應用程序時，我們就使用了一種名字為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論壇應用程序，此程序能夠經得起長時間的測試。它應該是不僅現在良好地工作，還應該在未來繼續工作—即使是當有人需要對該應用程序進行更改之時。
我想利用微軟 MVC框架開發此論壇應用程序。原因在於，這個框架可以使我更容易地編寫程序的測試代碼。而另一方面， MVC框架本身就從設計之初提供了對測試驅動開發的最忠誠的支持。
③ 程序設計和Web程序設計的區別在哪兒_web使用什麼設計程序
這個可以用ASP和ASP.NET的區別來解釋你的問題：
ASP.Net和ASP的最大區別在於編程思維的轉換，而不僅僅在於功能的增強。ASP使用VBS/JS這樣的腳本語言混合html來編程，而那些腳本語言屬於弱類型、面向結構的編程語言，而非面向對象，這就明顯產生以下幾個問題：
1、代碼邏輯混亂，難於管理：由於ASP是腳本語言混合html編程，所以你很難看清代碼的邏輯關系，並且隨著程序的復雜性增加，使得代碼的管理十分困難，甚至超出一個程序員所能達到的管理能力，從而造成出錯或這樣那樣的問題。
2、代碼的可重用性差：由於是面向結構的編程方式，並且混合html，所以可能頁面原型修改一點，整個程序都需要修改，更別提代碼重用了。
3、弱類型造成潛在的出錯可能：盡管弱數據類型的編程語言使用起來回方便一些，但相對於它所造成的出錯幾率是遠遠得不償失的。灶喚啟
以上是語言本身的弱點，在功能方面ASP同樣存在問題，第一是功能太弱，一些底層操作只能通過組件來完成，在這點上是遠遠比不上PHP/JSP，其次就是缺乏完善的糾錯/調試功能，這點上ASP/PHP/JSP差不多。
那麼，ASP.Net有哪些改進呢？
ASP.Net擺脫了以前ASP使用腳本語言來編程的缺點，理論上可以使用任何編程語言包括C,VB,JS等鏈螞等，當然，最合適的編程語言還是MS為.NetFrmaework專門推出的C(讀csharp)，它可以看作是VC和Java的混合體吧，盡管MS自己講C#內核中更多的象VC，但實際上我還是認為它和Java更象一些吧。首先它是面向對象的編程語言，而不是一種腳本，所以它具有面向對象編程語言的一切特性，比如封裝性、繼承性、多態性等等，這就解決了剛才談到的ASP的那些弱點。封裝性使得代碼邏輯清晰，易於管理，並且應用到ASP.Net上就可以使業務邏輯和Html頁面分離，這樣無論頁面原型如何改變，業務邏輯代碼都不必做任何改動；繼承性和多態性使得代碼的可重用性大大提高，你可以通過繼承已有的對象最大限度保護你以前的投資。並且C#和C、Java一樣提供了完善的調試/糾錯體系。
ASP（ActiveServerPages）是Microsfot公司1996年11月推出的WEB應用程序開發技術，它既不是一種程序語言，也不是一種開發工具，而是一種技術框架，不須使用微軟的產品就能編寫它的代碼，能產生和執行動態、互動式、高效率的站占伺服器的應用程序。運用ASP可將VBscript、javascript等腳本語言嵌入到HTML中，便可快速完成網站的應用程序，無需編譯，可在伺服器端隱如直接執行。容易編寫，使用普通的文本編輯器編寫，如記事本就可以完成。由腳本在伺服器上而不是客戶端運行，ASP所使用的腳本語言都在服務端上運行，用戶端的瀏覽器不需要提供任何別的支持，這樣大提高了用戶與伺服器之間的交互的速度。此外，它可通過內置的組件實現更強大的功能，如使用A-DO可以輕松地訪問資料庫。
之後，微軟又推出ASP.NET。這不是ASP的簡單升級，而是全新一代的動態網頁實現系統，用於一台WEB伺服器建立強大的應用程序。是微軟發展的新體系結構.NET的一部分，是ASP和.NET技術的結合。提供基於組件、事件驅動的可編程網路表單，大大簡化了編程。還可以用ASP.NET建立網路服務。
ASP與ASP.NET的區別：
1.開發語言不同
ASP僅局限於使用non-type腳本語言來開發，用戶給WEB頁中添加ASP代碼的方法與客戶端腳本中添加代碼的方法相同，導致代碼雜亂。
ASP.NET允許用戶選擇並使用功能完善的strongly-type編程語言，也允許使用潛加巨大的.NETFramework。
2.運行機制不同
ASP是解釋運行的編程框架，所以執行效率加較低。
ASP.NET是編譯性的編程框架，運行是伺服器上的編譯好的公共語言運行時庫代碼，可以利用早期綁定，實施編譯來提高效率。
3.開發方式
ASP把界面設計和程序設計混在一起，維護和重用困難。
ASP.NET把界面設計和程序設計以不同的文件分離開，復用性和維護性得到了提高。
④ 基於ASP.NET MVC框架開發Web論壇應用程序[1]
我想通過本系列文章從頭到尾構建一個完整的ASP NET MVC論壇應用程序 最終的目的是探討和推動使用ASP NET MVC框架構建應用程序的最佳實踐友局
簡介
在本篇中 我想先從全局方面介紹一下論壇應用程序的總體目標 在本篇中 我將討論一下避免代碼壞味道的重要性 還將討論如何利用軟體設計原則和模式來幫助你編寫適合未來改變的富有彈性的代碼 最後 我還將論證一下為什麼我選擇使用測試驅動開發方式構建本系列文章中的論壇應用程序
什麼樣的軟體是好的軟體
我不想僅僅為了構建論壇應用程序而任意構建此論壇應用程序 我的目標是盡可能構建最棒的論壇應用程序
這個目標立即引發這樣一個問題 什麼樣的軟體是好的軟體？是什麼導致一個應用程序比另一個應用程序更好一些或更差一些呢？在事先沒有一個關於 好軟體 的定義之前 我無法聲明我構建了一個完美的論壇應用程序
因此 下面是我對於 好軟體 的定義
好軟體是設計得易於修改的軟體
存在多種原因可能需要你改變軟體
)你可能需要在一個現有軟體上添加新的特徵 )你可能需要修改一個現有軟體中的錯誤 )你可能需要優化現有軟體 )你可能需要改進現有軟體的設計
一般說來 設計糟糕的軟體是難於改變的 有些軟體設計得如此糟糕 以致於每個人都害怕碰一碰它 我們大家應該都使用過設計得糟糕的軟體 當軟體不好時 你很希望它乾脆走開 甚至如果有機會的話 你可能想從頭開始重新編寫這款軟體
避免代碼壞味道
Robert和Micah Martin把糟糕的軟體部分描述為代碼壞味道 下列代碼壞味道意味著此軟體的書寫是相當糟糕的
)僵化性（Rigidity）—僵化的軟體是這樣的軟體 當你在某個位置作一改動時即要求對系統作出相應的一系列的更改 )脆弱性（Fragility）—脆弱的軟體是這樣的軟體 你在某個好鋒讓位置作一改動時即打斷另外多處的正常運行 )不必要的復雜性—不必要的復雜軟體是指過度設計的軟體 其目的是為了處理任何可能的改變 )不必要的重復—不必要的重復軟體中包含大量的重復性代碼 )晦澀性—晦澀的軟體是指難於理解的軟體
【注意】上述這些代碼味道在Micah和Robert Martin的著名《Agile Principles Patterns and Practices in C#》中得到充分的描述 在此 強烈建議讀者讀一下這本書 注意 上述這些代碼味道都與所有的代碼改變相關聯 每一個這些代碼味道都將妨礙代碼的改變
軟體設計原則
遵循良好的軟體設計原則 將有助於編寫軟體易於適應未來更改的軟體 軟體設計原則有若干 也不盡相同 例如 Cunningham和Cunningham Wiki描述面向對象設計的 個原則 //c /cgi/wiki?
其中提到的面向對象設計的前五個原則與Robert Martin及他的兒子Micah Martin編著的《Agile Principles Patterns and Practices in C#》中所基激主張的軟體設計原則是一致的 此外 Robert Martin還在Object Mentor開辟的博客上討論了這些原則 // objectmentor /resources/publishedArticles
此外 我還發現有另外兩本書中也提供了有關軟體設計原則的極其有用的信息 第一本是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的提法並不十分相同 但是它們卻十分相近
lishixin/Article/program/net/201311/14493