Re: [心得] 談.net mvc

[changkyle (瀧)]

※ 引述《ritchieHsu (我要努力向上)》之銘言：
: ※ 引述《TonyQ (沉默是金。)》之銘言：
: :         我突然想一想我發現這是值得討論的。
: :         網頁的基本形式是，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(魔鬼)還不是因為欠缺這些軟體工程的思維所造成的
: 　無奈老闆是聽不進去的

    看到 r大這篇不禁回一下，小弟目前也是在竹科某半導體廠擔任CIM/AUTO
    的職務，目前觀察到的情況大約是這樣：

    1)FAB最講究的就是快速與cost down，因此能動能用就好，千萬不能影響工廠
    2)建廠距今幾乎都超過10年以上，現行系統幾乎都沿用至今
    3)由於產能與需求的增加，舊有系統架構並沒有這些規劃與設計，理想的情況下
      必須要做更新，但是老闆不能接受付出了人力與時間、還有冒著上線測試時
      系統不穩定的風險，只為了『系統架構的更新』這種IE沒辦法算成錢還可能會
      損失錢的事情
    4)現在需求來了，系統主架構沒辦法支持時，各工程師只能各顯神通，偏偏能力
      素質不一，程式碼開始出現C&P、hardcode、奇妙的地方出現特別if-elseif...
      假設主系統是一間小透天，現在開始陽台外推，頂樓加蓋上面再加蓋，從旁邊的
      電線杆偷電，從隔壁家偷接第四台，防火巷擴建，自己埋條水管排到另一條
      排水溝等，接著悲劇就開始發生了。
    5)系統開始不穩定與脆弱，有些工程師trace code發現問題所在，發出了求救訊號，
      但由於2的因素無法從根本修改，只能想辦法依照現況修補，
      就好像水管漏水了，沒辦法把有問題的水管換掉，只能不停的在外面纏上止水布
    6)隨著人來人往時間流逝，系統翻新的難度越來越高，最後變成了不可能的事情，
      只能砍掉重練。但是因為牽連的層面越來越廣，老闆不能忍受讓FAB暫停讓你進行
      新舊系統切換只為了上一個功能一模一樣只所謂『架構較好』的系統
    7)現在另一個問題浮現了，因為系統不穩定讓OWNER的負擔加重，
      再加上需求或PROJECT的壓力讓人員離職率升高，一直不停的補新人，
      而新人一看也知道發生什麼事情，不是很快溜走，不然就是在上手之後
      因為不爽/無奈/無法處理而離職，讓情況更加不可收拾

    而且CIM屬性偏冷門，工作重點是FAB能順利的RUN下去，老闆根本不在乎
    什麼軟工程式技巧，能上手解決需求線上問題才是第一優先，
    ，經驗大於一切，最好是能馬上上手，所以小弟現在在公司也是隨波逐流，
    因為講再多也只是做死，做死就算了還沒績效，所以還是回家自己努力就好 XD

--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 112.105.82.201
→ TonyQ:不錯得經驗分享，置底討論數天。
推 umum29:推 SFC系統不可能大翻修 能改的只有一些report型系統
推 EAFV:理想跟現實是有差距的 而這中間去拿捏平衡看工程師的經驗與功
→ EAFV:力 理論上的最佳解這種東西通常是不存在或是死路(搞死你自己
→ EAFV:的路XD)
推 Cloud:小弟也做過CIM，解issue才是第一優先...但也衍伸問題
推 Vick753:推一個~
推 ryanwang:這種鴕鳥文化很常見，只能說接到這種爛缺算你倒楣@@
→ ryanwang:不禁讓我想到台塑工安事件...
推 syuasdio:推
推 a2350:基本上工程師領少少的薪水卻要做承擔責任的大事，不逃才怪
→ xsoho:但就算給很多聰明的人一看也知道是屎缺而拒絕
推 troylee:推..但是換了新系統, 當下的問題解決了, 未來是否還會面臨
→ troylee:陽台外推、樓頂加蓋同樣的問題呢？
推 Davidjcan:有看有推
推 Baternest:MES建廠的時候就已經決定好了 之後就是一直加功能吧~
→ Baternest:而且系統本身也是買來的 (IBM/HP/etc.) CIM沒能力換...
→ changkyle:這麼多大大回應小弟有點嚇到，小弟在獻醜一下，一般規模
→ changkyle:以上的FAB採用的是三層式，MES <-> 中間 <-> client
→ changkyle:而CIM建立的系統通常在 中間 <-> client這段，用以減輕
→ changkyle:與補強MES的loading與不足，還有大量的客製化系統
→ changkyle:但是那些自製的系統到最後幾乎都會走樣，而且一旦出問題
→ changkyle:會讓FAB停擺