.NET程序員應該熟悉的開發模式

最容易變化也最應該變化的是數據的出現方式。 　　在Java的各類應用中能夠說是四處可見MVC， J2EE貫穿MVC的概念， android的開發方式也是類MVC的， MVC結構對於作過Java應用的人而言簡直就是習覺得常。 NET這邊， 因爲以前微軟爲你們提供的各類winform、ASP. NET項目模範（好比那個petshopseries）將「三層」概念很好的灌輸到了. NET程序員的大腦中， 許多. NET開發者凡是作個東西都要搬出本身最拿手的IModel、IDAL這樣的神器。 然後者則是分層的角度去說。 　　一件很奇怪的事情， 其實這要歸結與. NET的早期開發技術ASP. NET和winform這些pagecontroller的模範讓許多人對三層誇誇其談卻對MVC視而不見甚至一無所知。 什麼是pagecontroller形式呢？搞. NET的大多都用過winform和webform， 咱們想要作一個程序， ok， 最複雜的方式就是拖拖拽拽幾個控件， 而後在一個叫codebehind的東西里寫這些UI事情的處置邏輯， 這樣一個程序就能出爐。 這種開發方式對於一些小軟件系統的開發其實效率仍是蠻高的， 後來人們看到其弊端---一旦修正UI， 事情處置就要跟着變， 可是業務仍是那個業務， 憑什麼要修正非UI的代碼？因而有人提出「三層」， 最樸素的理解就是將本來那堆事情處置裏的code分成業務代碼和數據庫訪問代碼並轉移到其它類中， 作多了就把那坨UI叫作UI， ú鰨赫飭椒糲opy自是daxnet文）　　MVC是一個很經典的結構， 而且其又其思想衍生出不少變種好比MVP, 傳統的MVC結構之一是這樣的（拿自動型MVC來講）：　　對於非天然MVC的框架　　對於ASP. 雖然能夠通過改造讓其支持MVC結構的開發（好比通過定製IHttpModule、IHttpHandler云云）， 可是在企業看來這些都算是邪門武功（由於這樣會喪失xxxform在開發上的不少特性好比疾速開發）。 什麼是mvp呢？其實mvp是MVC的一個變種。 那麼好， 咱們仍然使用designer和codebehind， 其實一個架構設計的好壞是取決於人而不是詳細的技術的， 只需咱們OO一時強pagecontroller同樣好用。 　　在MVP形式中咱們須要本身定製各個View（web頁面或許窗體. NET）對應的IView和IPresenter、IModel。 IView要對IPresenter暴露操做UI、數據綁定的接口， 舉個複雜的例子， 看上去寫成的要多些那麼一坨東西， 可是益處是顯而易見的， 這就是益處。 NET平臺的開發人員， 託微軟的福分咱們擁有一種更爲強大的模型---MVVM。 這應該算是作WPF/Silverlight應用的人必懂的一種結構， 這就爲咱們使用MVVM創造了可能。 　　View是什麼呢， 純的View只有xaml或許附帶必要的只與View自己相關邏輯代碼。 在MVVM中View與ViewModel總會有一種綁定關係， 一旦ViewModel中被綁定的數據發生改變View上的數據就會跟着變， 好比你的帳號密碼框內容發生變化， 關聯的ViewModel中的數據就會被框架自動通知到。 綁定是通過xaml語法來完成（雖然你能夠選擇用c#來寫但不符合mvvm的宗旨）， 而且綁定雙方的通知機制是有框架來完成， 也就是說一個會xaml和blend的美工只需事前和coder商量下「我們的xx和xx是在哪一個ViewModel上叫XXX的屬性的XXX屬性……」效果以後就能夠各幹各的了。 那麼ViewModel怎麼寫， 咋view中又怎麼綁定到viewmodel呢？首先咱們談ViewModel。 而後讓其餘ViewModel繼承這個基類。 　　爲了方便， 咱們能夠在app. 　　?≒S:雖然vs很強大， 但我的仍是建議熟悉xaml的綁定語法， 想當初用vs2008搞wpf的時候貌似尚未這麼方便的設計器。 。 ）　　原文連接：　　【編輯引薦】