engineering > 裏所有文章列表
In researching the origins of the MVC pattern, I came across an archived posting from the Usenet group comp.lang.smalltalk from 1994. The posting read, in part:
I thought you might be interested in a ‘bit of history’ on origin of the Model-View-Controller paradigm.
Prof. Trygve Reenskaug is generally cited as being the creator of the MVC concept. He worked with the Smalltalk group at Xerox PARC as a visiting scientist in 78/79. During this stay at Xerox PARC he developed the MVC. I know him well and have talked to him about this. He confirms it, although stating that it was a collaborative effort at Xerox PARC.
My first idea was to separate presentation from information because the information structure is reasonably stable while the way we need to see it and manipulate it varies with the task. (This idea stems from around 1970 when I first became interested in distributed systems.)
Trygve Reenskaug現在已從挪威大學退休，並對UML的規格製定貢獻良多。
這個故事告訴我們：
1、早點兒生當xxx之父的機會比較大(當然像愛因斯坦這樣的大腦就例外，他大概生在那個時代都還是會發明跟相對論一樣偉大的理論)
2、如果要找最原始的mvc範例，可以多看smalltalk的相關討論站。另外colin moock的EAS2一書中也大量模仿smalltalk 的精神(加上部份java的實作手法，因為他的co-author是java背景)
3、如果要找現代一點的mvc或mvp範例，java struts 是個不錯的管道，它是遵循 MVC model 2 的精神去實作，只是我個人覺得它將工作流程的tier切分太細，雖然非常有彈性，但非常不適合小型的案子使用，因為很容易就會被架構給淹死。因此上乘之道是瞭解struts的原理與部份實作手法，然後改寫出自已喜歡的方式，例如針對RIA的架構去改一個適合的mvc pattern出來，目前這方面我已經有相當的成果。
| by admin
unit test很重要大家都知道，但actionscript要用什麼工具來進行測試？(不，ctrl-Enter 叫compile，那不是測試，頂多只能說是人工測試)
as2unit 是最早出現的unit test工具。
flexUnit 是專給flex / mxml 用的工具。
這兩個工具都是以 JUnit 為基礎改版而來，因此使用方式都不差不多，
但要如何與既有的開發流程結合就是大學問了，
未來將會有一篇詳細的心得介紹。
| by admin
用flash開發ria 的人越來越多，而隨者flex的推出，現在大部份flash coder都已經聽過或大致瞭解 mvc/mvp 這幾種pattern的意義，甚至可能也實作過一些範例。
但最近越思考如何用flash實現真正完整的OO程式規畫，就越發現實際上目前大部份人在flash裏採的mvc並不是那麼的純正(當然有人會接者argue說為何一定要管純正與否？能work不就好了？這是個好問題，等日後有空再討論)。
簡單先整理一下目前的結論：
1、mvc是個pattern，就跟其它所有的pattern一樣也只是個方法論，因為要用何種技術去實作都是ok的，只是大部份pattern都是以物件導向技術為基礎做討論，因此讓人覺得pattern = oo (也就是說 mvc = oo)。
2、mvc 中的 view-controller 這一段是可以很合理的與model 切開分離的，這樣做可以保持彈性。
3、而model這一段，也就是oo分析裏面說的domain models (或三階架構用的 business objects)要如何實作，就不一定要是oo了，目前90%的書、網站範例與教學都是採用data-driven的方式來處理，例如將database傳回的資料放進recordset(或更極端的放進datagrid裏當容器)，而不是依照java/net的手法，將這些recordset再建構成適當的object instance。
所以可以得知 model 這塊裏面，可以用 data-driven直接做掉(dirty and quick法)，也可以乖乖的cast成適當的物件，而這裏採取的手法，就直接反應了程式師的編程風格與邏輯，是否要走物件導向，從這裏也就看得出來。
因此目前在使用mvc的flash開發者應該要清楚的知道，使用mvc不代表已經是物件導向，就像會用actionscript 2.0 也不代表就懂物件導向編程(試者問自已，上一次用interface是何時？真的瞭解為何需要 interface而不是inheritence就好？)
而至於OO這樣的方法對flash開發來說是不是 too overkill 這個問題(很巧的在flashcoder list上有一串精彩的討論，另外有一串 mvc what ? 也值得一看)，大底上來說是永遠不會有答案的，只能說這是選擇的哲學，oo有它明顯的好處(你知道的，不外乎就是彈性、維護、重覆使用….)，但也有為人垢病的地方(廢時、廢工…)，但我認為全程採用oo是一個 trade-off 的選擇，的確選擇oo一開始要付出的學習成本非常高，甚至生產力會大幅降低，但一旦完全上手成熟後，可以確保往後十幾二十年的開發品質，因為這段學oo的過程，不但會完全改變一個人的coding方式與技巧，連思考一個問題的方式也會改變，變的更條理、模組化，因此自然比較有可能一開始就將事情做好。
當然我也不否認寫了十年的 C(或任何其它非oo語言)高手，也一樣有辦法規畫出結構良好，簡單易懂的程式，只要將程式段落分清楚、切乾淨，這一切也是有可能做到的，只是考量目前常見的語言(java, c#, as2, perl, python…)都已經物件化，而oo本身所提供的思考方式與功能，不用似乎太可惜，再加上如果將來真的想將flash做為開發大型企業應用程式(不論是用flash或flex)，擁有完整且成熟的oo經驗已經是不可或缺的了。
所以，是該時後開始學啦。
ps. 經常被問到如果想學好flash 00的開發該看什麼書，過陣子我會試者列出清單，如果有電子書的部份也會想辦法放上網路。不過可以先給大家一個基本方向，以我的感覺，目前flash的進階書中，真正講到完整oo的並不多，colin moock那本EAS2.0(趙英傑先生已經完成翻譯並出版)可以提供學習 as2.0這個語言的完整教材，但對於用oo實作專案則明顯不足(書中那兩個例子都太單純不足以呈現實務中必然面對的挑戰)。
如果真要找書，我建議朝 java/.net 的方向去看，找一本從頭介紹 OOAD 與 code實作的書來看完，或許你看不懂書中的語法，但介紹概念的部份仍然非常值得學習，邊看邊想怎麼用actionscript去實作，並且結合flash的某些特性，就會覺得大獲啟發了。
| by admin
今天突然想到，一般人在用flash製作app時，都是將所有的處理邏輯放在client端進行，server端負責將資料從db裏撈出來傳到客戶browser的swf裏，然後透過那個swf進行操作，也就是說M-V-C 三者都放在client端。
但最近越研究如何用flash做真正oo的開發，就發現其實選擇或許不止如此。
以前用 asp/php/jsp的人工作流程大多是將M-C都放在server端，所有的 business object與data model都在server端處理完後才將結果生成html送回給客戶(的browser)，因此只有view這塊是在client端完成。
而今天突然想到一點，如果讓swf也扮演同樣的角色會是什麼情況呢？也就是說讓swf只負責view的部份，接收user的輸入指令，然後將訊息傳回server端進行商業邏輯部份的處理，等有結果後再將資料傳回swf，讓它負責顯示出來。
這樣的流程就會跟傳統動態網頁的三階式架構很類似，但前端換成swf即可享有更好的易用度與互動功能，例如大家最喜歡提的 drag-drop 或 filter 功能。
之所以會想到這點，主要是發現要想在client端的swf裏面處理所有的 business objects並且流暢的進行 OR mapping必需要花不少功夫，這句話講的明白一點就是，要在flash裏做到全oo的規畫與實作並不難，但討厭的地方在於persistance，如何將flash端的object 給完整的persist到db table裏，然後，更重要的，能有一套合理的取回策略(將table內的資料撈出來再組合成一個native flash object)，有做個oo程式的人都會瞭解，這裏面牽涉到許多 OR mapping, refactoring, modeling的技巧與選擇，而flash又不像java EJB可來回傳送 native object，因此整件事就變的更複雜。
以往用asp/php/jsp的人在這方面不會面臨太大的困難主要原因有：
1、他們本來就是server side的語言，因此不需負擔網路連線傳送的時間/機器成本，當object model與data model都在server端時，只要搭配良好的 object persistance layer與 db persistance layer，事情就解決了。
2、這三種技術早就有大量成熟的framework與layer套件可取用
因此順者這個邏輯想下去，才會想到為何不讓flash也變成同樣的情況？如果我們將所有的logic都放在server，只將最後的結果丟給swf(例如用grid元件顯示)去顯示，是不是就能解決這些OR mapping的問題了呢？
但很明顯的，如果這樣做，一來就喪失了flash做為rich client的特色，二來等於又回到過去web application所謂的 click-for-next-page 模式，那不如就繼續使用asp/php/jsp即可。
可是很有趣的一點在於，大家可以仔細想想現在flex採取的策略，是否跟前面提到的想法很像呢？mm開發flex時的產品策略就是鎖定既有的開發人員，希望這些人可以延用傳統的開發手法(所有的logic與model都在server端處理，最終的結果再生成swf傳給客戶端)與開發工具(xml)。當然腦子轉的快的人可能已經想到，現在外面有一狗票的swf library，例如php的ming library，我也可以自已diy flex的動態生成swf功能，但不同的地方在於flex提供的不止是 swf generator，它同時還完整包含了一套 framework與components，這些是目前大部份 3rd party swf library很難比美的(當然它昂貴的售價也是其它對手很難相比的 ><)。
從這個角度出發去看flex，就會很清楚的瞭解mm在想什麼，以及mm為何將flex定義成 persentation server，而不是一個像 brian lesser所講的 client side compiler(swf generator)，因為他們分別代表者兩種完全不同的思考方向呀！
(註：現在coldfusion 7出來了，裏面的flash form也是follow同樣的邏輯與方向，將flash做為一個view的替代品，而不是將model給搬到client端處理)
如果你問我的想法，那一條路比較好？
我覺得現在還很難取捨，基本上我偏向支持將mvc都放在flash端處理，而不只是view的替代品，在這個架構下，app server將只是flash與db間的中介橋樑，所有的business logic都在前端，等處理好後要persist時才將結果傳給app server，由它寫入db中(甚至如果用了類似 mssqlConnector這樣的flash原生組件，可能連app server都免了，這樣的情況下就是真正將mvc/object model/data model完整的搬到client端了)
選擇這個方向的主要的原因，一部份是當然是出自我對flash的熱愛與多年的coding經驗，所以它是一個熟悉的好工具，另一部份則是我相信flash做為一個rich client，有潛力發揮更大的應用，例如成為desktop app的前端之類的。
但選擇這條路要面臨的缺點也很多，一個就是前面提過的OR mapping(及其所衍生的諸問題)，另一個則是swf很容易破解，用asv可以輕易看到所有的程式結構，這也是將 business logic搬到client端時要面臨的最大威脅，而目前似乎也沒有很好的防衛方法，除非自已寫obfuscator。
因此目前只能說前途未定，flash做為ria client是很好的選擇，不論就視覺效果、使用者互動與經驗來看都是如此，但路上還有不少大小石頭得清掉才行哩~
| by admin
這篇文章提到了OO project必定經歷的過程，從 modeling(又分成 object modeling, data modeling)、mapping(一般稱為 OR mapping, 將 business object轉換為relational database的過程)、Test Driven(這是agile programming概念興盛後逐漸成為顯學的做法，XP也將此點列為首要任務，它確實是很重要)、Refactoring(當class diagram設計完程式也寫了一部份時，自然就會發現有重整class結構的必要，這也是上一篇文章介紹的書所講的重點)、performance tunning(這點的重要性就不用多說了，基本上tunning的點非常多，從程式碼本身的最佳化、資料庫內部結構的調整、到作業系統底層的設定，實在也是門大學問)
*Modeling. There are two modeling oriented activities, object modeling and data modeling, both of which would naturally be supported by normalization techniques. Neither object modeling nor data modeling are agile by themselves, it’s how you apply these techniques that count. Agile Modeling (AM) describes how models can be used to drive your development efforts in an agile manner, something I like to call Agile Model Driven Development (AMDD).
*Mapping. Because you’re using object technology and relational databases (RDBs) together you need to understand how to overcome the impedance mismatch between the two. That’s what mapping is all about. Because you are developing your object and data schemas in an evolutionary manner you will clearly need to evolve your mappings over time. Similarly, difficulties in mapping may motivate changes to either your object or data schemas, perhaps even both at once.
* Test-driven development (TDD). TDD is an approach where you write a new test, you watch it fail, then you write the little bit of functional code required to ensure that the test passes.
*Refactoring. A code refactoring is a small improvement to your source code that improves its design without adding new functionality. A database refactoring is a small improvement to your database schema that doesn’t change its functional or informational semantics. Database refactoring, like code refactoring, enables you to evolve your design over time to help you to meet the new needs of your stakeholders.
*Performance tuning. Because modern systems use several technologies, including both object technology and RDBs, developers must be prepared to tune both these technologies and the interactions between them.
來源
目前我做的事就是將這些 方法論 逐一套用到 flash RIA開發上，試者從 J2EE/.NET Framework身上學習 tried-and-true心得，並建構一套flash適用的 framework，或至少是一個容易接受與使用的方法論，這點對於大部份屬於半路出家寫程式的資淺 flash coder或剛踏進flash coding領域的科班學生會非常重要，對於公司內team 合作的成敗更是重要，這是為何我願意花大量時間研究此主題的原因。
當方法論定案後，接者我會朝flex方向前進，觀察mxml的工作方式是否能更切合正統oo方法論的實作，目前在國外已經出現這種現像，渴望擁有正統oo規格的flash玩家(如skinner、aral等)都已開始研究flex，但至於成敗則還在未定之天，我們等者看吧 
| by admin
Next Posts
Previous Posts
