很有趣的觀點，文中所謂的 ajax engine, 其實就是把 view-controller搬到client端進行，所以可以享受 shorter-response-time，例如 orkut, google, gmail等。
這個概念對專職寫 flash ria的人來說應該一點兒也不新奇吧？實際上orkut或gmail就是非常適合用ria重新改寫的對象，想想看， 能夠有outlook的功能與操作介面，但又能透過web使用，不是很棒的玩意嗎？
今天突然想到，一般人在用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是很好的選擇，不論就視覺效果、使用者互動與經驗來看都是如此，但路上還有不少大小石頭得清掉才行哩~
這個問題我想了很久，wp這種 master catergory與 sub-catgory 的分類方式，乍看之下似乎很方便，提供幾種 看同一份資料來源 的 不同view，也就是同一篇文章可以從不同的點連結到。
但它的問題也很多，例如這樣真的是找尋文章最好的方式嗎？樹狀的結構圖有其好處，但對於 資訊取得 卻不見得有正面效果，尤其當文章非常多時。
或許像drupal這種 meta tag 導向的系統會更適合，但它的問題在於手法太新奇一般人要熟悉還真不容易，更惶論要切進去惡搞它的tag系統，但如果真成功了，應該會是blog(或所有cms)的全新出路。
當然，三句不離本行，我其實是想借用那套tag系統再加上一個flash front-end…就像現在很多人試者為wp的某些功能加上flash介面。
這篇文章提到了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，但至於成敗則還在未定之天，我們等者看吧 
Refactoring: Improving the Design of Existing Code
最近一樣忙者在弄actionscript framework, 很多東西都師法 C#/.netframework ，越做越覺發現正統的oo手法是非常重要的，而在oo的領域裏，refactoring是不可避免一定得進行的過程，這是本很棒的參考書。
