2010-11-05 63 views
2

我即將開始一個新項目。我想要一些指標來確定我是否應該使用ASP.NET MVC。確定是否應使用.NET MVC

(除使用ASP.NET MVC的經驗...)

有哪些指標ASP.NET MVC模型應該開始一個項目時,可以使用?

什麼是一些指標,ASP.NET MVC模型應該不是在啓動項目時使用?

+3

我不把這作爲答案,它不值得,但如果你要與ASP.NET一起去,那麼去ASP.NET MVC - 默認的webforms實現是hellspawn。 – Jamiec 2010-11-05 15:13:09

+1

Megadupe:http://stackoverflow.com/search?q=why+use+asp.net+mvc – jfar 2010-11-05 15:26:37

回答

5

嗯。我想過這個問題好,我想這將是接受當且僅當使用Web窗體:

  • 你的團隊成員有沒有web標準的想法,他們更喜歡使用Visual Studio開發的網頁。
  • 你不關心TDD。
  • 你不關心對象耦合和其他「深奧」的SOLID原則。
  • 您錯過了開發Windows應用程序,並且您希望Web開發儘可能接近該體驗。
  • 您不關心最大化性能或製作無會話的Web應用程序。
  • 你想快速和骯髒。

如果上述任何一個語句都是錯誤的,我建議您忘記WebForms並深入ASP.NET MVC。

編輯:

還有另一個理由不使用ASP.NET MVC:

  • 你都弄好COMMITED到的WebForms(例如,花了很多錢的WebForms組件或培訓)。

不幸的是,這會使上述任何原因無效。

+0

很好的答案。相當於「如果你是一個winforms開發人員,webforms可能適合你」,這不是太遠了。 – Jamiec 2010-11-05 15:24:43

+2

很好的答案。但根據經驗 - 使用ASP.NET MVC! – BritishDeveloper 2010-11-05 17:16:29

2

如果您想要或需要可測試性,絕對要使用MVC。這幾乎是WebForm中幾乎不可能的MVC的唯一區域。除此之外,這完全是主觀的。

這兩個框架在大多數領域幾乎同等適用。在我看來,它歸結爲一件事:

你更喜歡使用頁面和基於組件的框架(Webforms)或基於動作的MVC框架(顯然是MVC)。

在我看來,Webforms正在遭受的壓力比它應得的要嚴重得多,老實說,它似乎現在討厭Webforms並且很喜歡MVC。

兩者都是簡單的工具來達到你的目標,選擇你最喜歡的。而已。

+0

在我的辯護中,我會說我總是討厭WebForms ...我是[Castle Monorail](http://www.castleproject.org/monorail/index.html)的早期採用者,因爲幾乎沒有。 .NET開發人員甚至知道MVC是關於什麼......但我們同意一點:WebForms得到很多不好的新聞......人們仍然在談論它! .NET開發人員應該忘記它甚至已經存在,並開始談論其他的東西! :-) – rsenna 2010-11-06 01:53:04

2

我現在通常會使用MVC運行。但webforms不是那麼糟糕,而且4。0調整使事情更符合現代Web標準和工具。他們真正能夠發光的一個地方就是內聯網應用程序 - 像SEO和視圖狀態不佳的缺點要麼無所謂,要麼成爲優勢。 Drag-n-drop ajax很不錯,許多開發者仍然使用ajax控件工具包比jquery更好。

在可測性方面,我會同意MVC在UI層中有點可測試性,但是應用程序的肉應該低於吃水線。而且,在MVC(DefaultModelBinder anybody?)中也有一些黑魔法和巫術。在這兩種情況下你真正需要的是真正的UI集成測試,並且他們通常不會在乎任何方式。

所以做你知道和愛。

+0

MVC在所有圖層中測試得多。 WebForms不是 - 你可以將它變成可測試的,但這不是它的真實性質。就像標準的K&R C一樣,它不是面向對象的語言,但可以被融合爲一個(使用結構和虛擬指針表):這是可能的;它也很難做到(MVP任何人?)。但是,是的,我確實同意WebForms對內聯網,點擊式RAD開發很有用,所以+1。 – rsenna 2010-11-06 02:36:32

0

UI複雜 MVC架構的主要限制是缺乏視圖狀態,它不提供任何綜合的解決方案來管理UI的組件的狀態。 asp net webfom提供了一個集成的解決方案來管理它。 因此,如果您計劃通過實現多個窗口小部件,那麼webform就有一個內置的解決方案來存檔問題(代價是更加複雜)。

相關問題