Re: [心得] 談.net mvc

[ritchieHsu (我要努力向上)]

※ 引述《TonyQ (沉默是金。)》之銘言：
: ※ 引述《prag222 (prag)》之銘言：
: : → atst2:想請教一下，mvc的pattern其實很早就有了,可是我看板上最近   08/06 20:01
: : → atst2:似乎很多網頁相關的都會把這拿出來講，有點當成新東西的意思  08/06 20:01
: : → atst2:在, 是以往網頁技術沒有用到MVC的pattern嗎？還是最近有什麼  08/06 20:02
: : → atst2:特別的,關於MVC的新想法呢？                                08/06 20:02
: : → atst2:當然，即便以desktop app來說, MVC依軟體規模，也常變型為　  08/06 20:06
: : → atst2:MC-V or CV-M 的型式，不過概念上應該是不會有太多更動的.    08/06 20:07
: : → atst2:過去的網頁技術，在實現MVC上有特別困難嗎？我還以為網頁     08/06 20:07
: : → atst2:反而是最能體現MVC的部分呢...                              08/06 20:08
: : → atst2:所以這裡的MVC指的是某種實作MVC pattern的方式囉?           08/06 20:08
:         我突然想一想我發現這是值得討論的。
:         網頁的基本形式是，page base，
:         一個 url 的連接，兩個常見 http method 的實作 (get/post)。
:         如果有玩過cgi / servlet / 早期 php / asp（非.net），
:         應該對那種有個 output stream (response) 一路 write 到底的 AP很有印象。
:         web 上談 MVC 的複雜度在於
:         1.html 其實是 view 的東西，所以一開始沒注意就容易髒掉，
:           變成一邊寫 view 一邊撈資料，這點一直到有一個階段之後才開始改善。
:           以 asp 體系來講，從 asp.net 就開始拆 controller，
:                   也有比較豐富的helper 來做這些事情，板友所講的 .net mvc ，
:                   應該是 .net 3 還 3.5 以後才推出的新 pattern（吧）。
:                   （歡迎勘誤，我實在有點久沒碰 .net 系列了。:P）
:           以 J2EE 體系來講，從早期的 java bean 實作到 jstl 等各taglib實作，
:                   java bean 或 jstl 都還是比較接近 view base 的東西。
:                   再到現在常見的 struts 這種先讀完資料再進行畫面的分配的作法。
:           以 PHP 體系來講，像是 CodeIgniter 這類的 solution就算是比較晚成的，
:                   現在接受度也正在抬頭。
:           當然也有新興的語言/框架是直接就把這件事作進他們預設的工作流程，
:           像是 ROR 就是個預設的案例就希望你寫 controller 的作法。
:         2.寫網頁的時候哪些是 mvc 要討論的重點？ mvc 對網頁適不適合？
:           這個就是大哉問了。
:           a.一般來講網頁至少有一件事情是mvc該作得，
:             我認為資料的讀取(m) 應該先於 view 的生成。 :P
:             也就是我個人比較喜歡 rails 或 struts 這類的 solution，
:             在進入到頁面之前，先進行純資料讀取的程序。
:             但因為網頁大多是由許多片段頁面互相 include 組裝而成，
:             所以這資料讀取的作法怎麼作比較有效率跟可再利用，並不容易。
:           b.controller 的角色定義明不明確
:             一般 AP 狀況下，controller 基本上應該連事件的處理等都處理，
:             但是 web app 因為 stateless ，
:             所以對事件的處理跟資料的保存有很大困擾。
:             i.controller 有人退守到 url base 的作法，
:               也就是透過特定路徑來進行特定操作，伺服器端只認 url 。
:               需要 client 互動的，就拆到 javascript 去做，
:               javascript 事實上也參與了 controller 的部份角色。
:               (這個應該是躲不掉，只是比例問題而已，
:                web 架構上 controller 先天就被切割成兩部份。 :( )
:            ii.透過特定的格式在每次 request 時保存狀態以達成事件操作
:               像 .net 的玩法就是預設透過 viewstate 保存狀態，
:               回到伺服器端的時候以此狀態來進行對應的事件操作。
:               其實就早期來講是蠻聰明的點子，因為對開發者負擔小，
:               對使用者來講討厭歸討厭，但是久了也就習慣了。
:               但現在由於網頁設計的多元化跟 javasript 的應用變多，
:               所以這樣的潮流也在順應時勢修改，
:               像是 ajax .net framework 就是個還算有趣的嘗試。
:               雖然我當時用 ajax .net framework 的想法是他受限於原本的框架，
:               所以用起來有很多有點彆扭或者意外的地方，好幾年過去了，
:               不知道現在有沒有好一點。:P
:               GWT 類的 solution 也差不多可以放在這裡，
:               另外 rails 也有提供 form helper 算是簡化這件事情，
:               基本上也就是走 restful 路線實作http method，只是有util幫忙。
:           iii.順帶一提，我現在公司的作法，對這件事情算是採取比較激進的態度，
:               我們把狀態放在 session ，用某些有效方式去管理他使他不leak，
:               以此為基礎來發展互動性較高的 controller 。
:               所有的事件基本上都是跟對應的 java object 去進行操作，
:               並封裝元件成為 server sdie 的類別，
:               對開發者來講可以相對較為輕鬆的透過 java 去進行開發。
:             就目前我所看到的案例來講，效果真的很不錯，而且元件再利用率也很高。
:             而當你真的需要寫 js的時候，可以把重點放在寫重要的 js ，
:             那種小的畫面切換，在伺服器端就可以有效處理這邏輯了。
:         c.對 template engine (view) 的不滿
:             考慮到資料模組的實現，html 對很多人來講是不夠用的，
:             所以舉凡 java/php 等，幾乎都有特化的 framework 試著處理這問題。
:             目前也都還在發展中。
:         -----------------------------------
:         MVC 的重點在於，對開發者來講，
:         你該認定的 M V C 三者的歸屬會在程式碼呈現出什麼樣子。
:         因為這是所謂的認同跟學習曲線，
:         而在於各 framework 跟語言怎麼實作 MVC 都還在各種嘗試的狀況下，
:         MVC 其實討論的是「這個 MVC 的形式合不合用」，而不是 MVC 本質上的概念。
:         事實上 MVC 本身的概念算是比較空泛的，他不是方法論，
:         而是比較偏設計原則的東西，在設計上也比較偏向於各自表述的作法。


  看到這些文章 又讓我懷念起來 已經快兩年沒碰新技術了

  不知道現在java/.net這兩大陣營有誰麼新玩意兒出來嗎?



  我目前是停留在 struts/spring MVC/JSF/RichFaces 那個時代

  看現在的年輕一代的開發者也頗喜歡用adobe flex,這應該是RIA的MVC架構


  有時候為了快速弄些小報表 都直接套spring MVC,用起來蠻輕快的

  我在某半導體廠工作,裡面IT/CIM的員工幾乎都沒聽過MVC

  更何況dessign pattern或loose coupling等軟體工程的觀念

  9成以上的系統都是用VB/Delphi傳統式win app開發出來

  新人進來也沒被正規SI觀念洗禮過,所以也跟著被污染 一個method萬行code到底

  一個button_click的事件,含SQL都可以塞入好幾千行code

  更別提有flow controller/model/entity 組件的觀念


  惡性循環下　導致系統越來越難維護

　衍生問題一堆 還要卯起來建立一些defense機制來補洞

  這是軟體業和電子業IT最大的差異


  電子業IT >> 能動為第一優先考量,管你用什麼方法

  軟體SI業 >> 強調鬆偶合架構/dessign pattern/OOAD等來建出一套能動的系統


  雖然我現在不走技術導向的職務,不過我依然站在SI業的開發思維

  畢竟每次系統發生大問題,造成公司(工廠)營運損失　

　最後的找出的root cause(魔鬼)還不是因為欠缺這些軟體工程的思維所造成的

　無奈老闆是聽不進去的

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 111.255.166.149
※ 編輯: ritchieHsu      來自: 111.255.166.149      (08/07 09:01)
→ andymai:一個Method萬行Code到底~好慘...所以現在人家拿著寫了幾萬
→ andymai:行的Code來炫耀~我都很想反問:你有設計架構嗎???
→ karcher:遇到functional programming能不動就不動。要動就直接打掉
推 vvppqqvv:用MVC未必會比較好維護 真的.............
推 vvppqqvv:這世界沒有甚麼萬靈丹
→ andymai:用MVC最起碼不會~也不應該看到麵條式的code~而且應該分得
→ andymai:很清楚~如果它沒有那麼多好處~微軟何必在搞了WebForm之後~
→ andymai:又回頭學人家搞了MVC???
→ apiod:所以4F覺得一個method萬行code比較好維護嗎
推 guest0079:樓上,我代4樓回覆你:對! 用電子業的思維就是好維護!
→ guest0079:搞MVC 搞物件導向 搞design pattern 搞框架？
→ apiod:請問什麼是電子業的思維?
→ guest0079:程式超好維護的耶,但開發者人一走,新接手的人雙手一攤
→ guest0079:問你什麼是MVC,你還要不怕麻煩地訓練他嗎?
→ apiod:MVC這些東西不就是為了後人比較好維護才用的嗎?
→ guest0079:不如自已先雙手一攤直接給他萬行code叫他自已想辦法
→ apiod:........這樣哪有比較好維護
→ guest0079:這就是電子業的思維啊!我管理上維護得很好,是新人太弱
→ guest0079:請不要老是用程式設計師的觀點來看"維護"這兩個字
推 lovdkkkk:能維護與接手萬行 method 也是一種強 XD
→ apiod:寫程式不用程式設計師的觀點要用什麼觀點呢?
→ apiod:給萬行code叫他自己想辦法 你維護得很好 新人看不懂是他太弱
→ apiod:你說這就是電子業的思維  那換成MVC有什麼不一樣嗎   新人看
→ apiod:不懂MVC不也是他太弱?
→ andymai:只是不想教新人而已吧...既然不想教~那用MVC或是寫萬行又
→ andymai:有什麼差別呢?
→ andymai:噗XD 樓上回得比我快XD
推 leicheong:我會覺得新手改code而不是加新功能的話, 會不會MVC是
→ leicheong:沒差... 反正改運算的部份多半在Model, 那裡多半已經有
→ leicheong:足夠種類的code/attribute可供「抄考」了... :P
推 vvppqqvv:MVC真的那麼好那麼神大家找用了
→ vvppqqvv:早用了
→ vvppqqvv:那些早期前輩真的不知道有MVC?
→ vvppqqvv:只能說想法不同
推 vvppqqvv:選擇一method萬行code跟選擇MVC或其他架構都在自己
→ vvppqqvv:而且.........
→ vvppqqvv:你還沒去人家那裏之前
→ vvppqqvv:人家用萬行CODE寫得好好的
→ vvppqqvv:我覺得這件事就是這樣
→ vvppqqvv:沒有說會甚麼架構就比較強
→ vvppqqvv:不會就比較弱
→ vvppqqvv:就是一種想法而已
→ apiod:你一開始說MVC架構未必比較好維護   請問你可以提出幾個使用
→ apiod:MVC架構卻很難維護的程式例子嗎?
→ apiod:如果前人都是寫萬行code  你照著寫當然沒問題  畢竟要改架構
→ apiod:太麻煩，但如果你個人在開發新軟體  為何寧願寫萬行code也不
→ apiod:願導入一些物件導向的概念?
推 pingsky:話說不曉得在電子業裡開發新軟體的機會多不多.....
推 edward13:電子業跟人扯什麼MVC..雞同鴨講..維護你的萬行code就好了
推 vvppqqvv:那你又能提出導入MVC就是好?
→ vvppqqvv:無聊.........
→ vvppqqvv:放大絕了是嗎
→ vvppqqvv:要放大家來放阿請你提出實質數據證明MVC就是好
→ vvppqqvv:開發新的我也會看同事是不是接受
→ vvppqqvv:因為不接受你又要硬幹
→ vvppqqvv:到頭來都是你頭痛
→ vvppqqvv:今天到一個新環境
→ vvppqqvv:你要就接受不要就自己想辦法
→ vvppqqvv:你絕對有抱怨的權力誰沒維護過萬行code?
→ vvppqqvv:問題是我不認為MVC就是萬靈丹
→ vvppqqvv:就這樣好嗎?
→ vvppqqvv:前面就說了VB 之類的人家不就跑好好的
→ vvppqqvv:雖然後面的人難維護
→ apiod:我沒說他是萬靈丹啊  我只是想知道你為何認為他不好?
→ vvppqqvv:但是今天對調MVC就不會有這種情形嗎
→ vvppqqvv:更何況今天的環境大家都處在萬行CODE的階段
→ vvppqqvv:不然今天給你導入阿你想怎樣做?
→ vvppqqvv:給你最大的權力你來導入你夠這個本事嗎?
→ apiod:看起來你只是為了反對而反對   你根本沒用過吧
→ apiod:你似乎本事很大的樣子   我還是不要跟你吵好了
→ ritchieHsu:v兄應該是電子業,別太激動,MVC是一種軟體工程基本的
→ ritchieHsu:thinking,程式寫久了,沒人逼你用 你也會不知不覺就這樣
→ ritchieHsu:用,唯有不經過大腦思索的coder才會寫出萬行(新)method
→ ritchieHsu:另外,vb/delphi任何程式語言都可以寫出MVC pattern
→ ritchieHsu:把event/flow controller/Data access logic/entity
→ ritchieHsu:抽離出來有很難嗎?一個萬行method裡面塞滿好幾段百行
→ ritchieHsu:SQL會好維護 ???
→ ritchieHsu:另外MVC的思維人家早用了,20~30年前用C也可以寫出這樣
→ ritchieHsu:的"精神",現在只是多了工具框架讓我們方便套用
→ ritchieHsu:不過話說回來,電子業軟體能力差也是活的好好的,能出貨
→ ritchieHsu:為第一優先考量,誰管系統怎麼寫的,因為那不是公司重點
→ ritchieHsu:這是個無奈也無法改變的事實,大家笑笑看開就好
→ TonyQ:其實這種事情我覺得跟技術架構的頭很有關係
→ TonyQ:如果當年導入的人就很有觀念，那就不會這樣。
→ TonyQ:但是電子產業哪來很有觀念的人（除非運氣很好），
→ TonyQ:所以才會變成普遍是這樣。不過既然已經夠用了，也不一定需要
→ TonyQ:改。但是隨著產業的需求如果有上升的話，應該還是會往好的
→ TonyQ:方向演化。
→ ritchieHsu:能改變(善)的就改變,不能改變的就隨波逐流,反正萬行
→ ritchieHsu:method在加入我新增的兩百行也沒差了...
→ ritchieHsu:T兄點到重點了,開創元老們思維真的很重要,因為後輩都是
→ ritchieHsu:跟著他們的思維
→ TonyQ:我是覺得現有的萬行method 只要需求有在增加，到某個程度會
→ TonyQ:變成成本高過重新組織的。（所謂的程式已死...）
→ TonyQ:那時候就會是下一個演化的開始。只是什麼時候達到那個程度，
→ TonyQ:也或許不會到達那個程度。這就要看產業的需求了。:P
推 lovdkkkk:推 20~30年前用C也可以寫出 MVC
→ gname:沒有絕對完美的方法,用物件就有人把物件寫爛了,用MVC就有人
→ gname:就有人把MVC寫爛了,基本上方法與觀念都不是問題,問題是"人"
推 atpx:<--維護高度OO的系統的人舉手....老實說不覺得比較好維護
→ atpx:基本的CRUD檔案要追快20個檔案才找的到, 很累....
→ atpx:每個檔案都繼承+實做一堆, 然後code都是this.OO(this.XX)
→ atpx:非常不直覺
推 Apohades:樓上沒有文件可以參考嗎? 有規格文件可以看的話
→ Apohades:找個CRUD應該沒有這麼誇張....