前些日子看到
Adobe Developer Center上的一篇文章很不錯，是關(guān)于如何開發(fā)RIA的，現(xiàn)在翻譯過來，給自己當(dāng)參考。由于翻譯經(jīng)驗尚欠缺，文中定有生硬之處，望見諒。歡迎大家對不到之處提出批評。
原文是：Building RIAs from Front to Back – Part 1: Understanding the Approach
原文地址：
http://www.adobe.com/devnet/flex/articles/frontback_pt1.html聲明：本文的中文版版權(quán)屬于本站和我，如果要轉(zhuǎn)載請注明出處，請遵循創(chuàng)作公用協(xié)議，勿用于商業(yè)用途。：）
從前往后開發(fā)RIA——第一部分：理解這種方式
現(xiàn)在我們不再被原始的界面控件和難以理解的請求/響應(yīng)（request/response）體系結(jié)構(gòu)所束縛，富因特網(wǎng)應(yīng)用程序（Rich Internet Applications，以下簡稱RIAs，譯者注）正在改變我們在網(wǎng)上處理事情的方式。隨著
Adobe Flex 2.0 Beta 的發(fā)布，使web開發(fā)者構(gòu)建出比較豐富的應(yīng)用程序變成了現(xiàn)實。
但是隨著技術(shù)的發(fā)展，對傳統(tǒng)web開發(fā)者的觀念也提出了嚴(yán)峻的挑戰(zhàn)。我們經(jīng)?？吹竭@樣的問題：剛剛接觸Flex的web開發(fā)者試圖用‘以頁面為中心’或‘請求/響應(yīng)’（request/response）的觀念構(gòu)建RIAs。為了充分發(fā)揮RIAs的優(yōu)勢，開發(fā)者必須開始用RIAs的方式思考，把注意力集中到他們提供的豐富的用戶體驗（user experience）上面來。
這篇文章是開發(fā)者中心（Developer Center）的一系列文章中的第一篇，這一系列文章探索一種創(chuàng)新的，被證明有效的開發(fā)RIAs的方式。這種方式就是把注意力集中在用戶體驗上而不是其它。在這篇文章中我們會介紹一種“從前往后（front to back）”開發(fā)的觀念，在這種開發(fā)方式里，用戶體驗成為了開發(fā)過程中的第一驅(qū)動，而不是事后才考慮的事情。我們將討論如何利用Flex 2.0 Beta來實現(xiàn)這種方式，F(xiàn)lex 2.0 Beta的特色使得這種方式非常成功。我們還將針對如何用這種方式將下一代的軟件移植到web上給出一些提示和建議。
這一系列文章不是關(guān)于理論和方法的。它告訴你如何利用Flex 2.0構(gòu)建強(qiáng)大的RIAs以及開發(fā)過程中“從前往后”這種方式的價值。在下面的四部分中，你將學(xué)會如何去做下面的事情：
設(shè)計并布局你的應(yīng)用程序
用Flex，F(xiàn)lash，HTML為你的程序做外殼（skin）和自定義你的程序。
利用模型（models）在多個數(shù)據(jù)源之間進(jìn)行方便的切換。
把你的應(yīng)用程序整合到企業(yè)級應(yīng)用中。現(xiàn)在開始著手吧我們經(jīng)常忘記一個事實：我們最終的用戶是我們的客戶。他們是那些付錢——直接或間接地——讓我們擁有工作的人。非常奇怪，傳統(tǒng)的應(yīng)用程序開發(fā)方式并沒有把注意力放在最終用戶所關(guān)心的——用戶體驗問題上。用戶不關(guān)心設(shè)計模式或者優(yōu)雅的代碼重用。他們關(guān)心的是他們?nèi)绾闻c你給他們創(chuàng)建的應(yīng)用程序進(jìn)行交互。然而傳統(tǒng)的開發(fā)小組往往把注意力集中在了系統(tǒng)的后臺，把用戶界面只作為事后考慮的事情。在過去的十年中，J2EE,CORBA以及其他分布式開發(fā)的風(fēng)險顯著地突出了這種矛盾。
現(xiàn)在我們花一點(diǎn)時間把軟件產(chǎn)業(yè)和幾乎任何其他的產(chǎn)品行業(yè)比較一下。在軟件產(chǎn)業(yè)中，你設(shè)計加工軟件的方式同你處理幾乎任何其他產(chǎn)品都有根本上的不同。你往往會以我們所說的“從后往前”的方式工作。這就是說，我們中的大多數(shù)都會先將工作集中在后臺的引擎和API上，而這個時候我們并不知道用戶界面是否會連接到這個API。
這種思考方式同那些十分成熟的、已經(jīng)確定的產(chǎn)品行業(yè)制造其他任何產(chǎn)品的思考方式相違背。例如，如果你想要造一輛汽車，你會在構(gòu)思它的引擎之前，先用粘土建造一個原型，然后用鋼鐵建造一個原型，然后把工作集中在如何讓用戶在汽車中有完美體驗的細(xì)節(jié)上。如果你不知道引擎區(qū)有多大的話怎么知道你需要什么大小的引擎。汽車工業(yè)，像所有其他成熟的產(chǎn)業(yè)一樣，開發(fā)加工的方式是“從前往后”。這就是說，他們先設(shè)計用戶體驗，然后根據(jù)用戶體驗去開發(fā)最終的產(chǎn)品所具有的特征和功能。
軟件產(chǎn)業(yè)有很多需要從傳統(tǒng)的產(chǎn)品開發(fā)中學(xué)習(xí)。用“從前往后”的方式去設(shè)計和開發(fā)軟件，這種想法雖然奇怪，但是卻非常的有用。它可以讓我們在短時間內(nèi)開發(fā)出更好，更豐富，更強(qiáng)有力的用戶體驗。
“從前往后”工作一次又一次地，我們在永無止境的設(shè)計會議上坐著，假定每一個進(jìn)入房間的人是股票持有者然后嘮嘮叨叨地討論，就這樣日復(fù)一日，試圖提取出并撰寫出一份應(yīng)用程序需求文檔。大多數(shù)人多次發(fā)現(xiàn)，以這種方式得到的需求總是以錯誤結(jié)束。
導(dǎo)致這種搜集需求的方法非常困難的原因有很多。最顯著的一個原因就是在這個過程中沒有真正請到領(lǐng)域內(nèi)的專家。（意思就是專家疲憊不堪不愿工作時就不再是專家了，譯者注。）在多日討論需求之后，即便是最充滿熱情的用戶也會精神疲憊，最終導(dǎo)致為了結(jié)束這個苦差事而機(jī)械地同意所有的事情。最后，生成了一份非常長的需求文檔并送回到專家那里簽字。不幸的是，這些文檔每一份都“看起來”很正確，直到程序已經(jīng)創(chuàng)建結(jié)束幾個月之后，需求分析偏離了目標(biāo)這個事實才顯現(xiàn)出來。
用實物模型（Live Mock-ups）打動用戶在“從前往后”的開發(fā)中，你開發(fā)用戶界面并用它確定程序的功能需求。傳統(tǒng)地，如果從根本上為用戶界面創(chuàng)建原型，常常用Microsoft Visio等工具的靜態(tài)線框（wireframes）來設(shè)計。雖然Visio是一個非常好的設(shè)計圖表的工具，但是它缺少你在為程序創(chuàng)建線框的時候真正需要的交互能力。
我們發(fā)現(xiàn)Flex本身就是做這種工作的好工具，因為它給我們提供了一種前所未有的高效的開發(fā)環(huán)境，讓我們的開發(fā)者可以很快地創(chuàng)建出漂亮的線框，讓用戶從一開始就近距離接觸到最終的程序。
當(dāng)我們作完這些具體的線框時，一種奇妙的事情發(fā)生了。在前面的會議上會打瞌睡的那位領(lǐng)域內(nèi)的專家開始活潑并真正的興奮起來。由于能夠看到他們將會怎樣操作這個程序，從而使他們開始思考什么是他們真正需要的以及如何把這些單獨(dú)的程序集成到一起。最終的結(jié)果將會是一份非常精確的需求分析。
建立數(shù)據(jù)模型在這個過程中，創(chuàng)建了一個簡陋的數(shù)據(jù)模型，用來說明關(guān)鍵的關(guān)系和數(shù)據(jù)點(diǎn)。當(dāng)每個界面慢慢實現(xiàn)的時候，開發(fā)組會維護(hù)一個與之匹配的數(shù)據(jù)模型，它會引發(fā)我們思考那些關(guān)系：顧客可以有一個以上的銷售代表還是一個顧客永遠(yuǎn)只能有一個銷售代表？通過“從前往后”的方式開發(fā)，用戶提供了更精確地需求，這會讓那些機(jī)敏的開發(fā)小組及早地發(fā)現(xiàn)那些緊要的問題。我們都知道在最后一分鐘把數(shù)據(jù)關(guān)系從‘一對多’改為‘多對多’的那種痛苦。用戶一開始的時候越忙碌，最初的到的數(shù)據(jù)模型就越精確。這縮短了開發(fā)周期，也讓會用戶感到滿意。
綁定到靜態(tài)數(shù)據(jù)一旦界面布局完成之后，接下來要做的就是把用戶界面的控件和靜態(tài)數(shù)據(jù)綁定起來。Flex 2.0使得把XML文件中的靜態(tài)或者“模擬”的數(shù)據(jù)綁定到RIA這件事情變得很簡單。綁定數(shù)據(jù)讓程序看起來可以成功運(yùn)行，這可以讓你確定你的界面將完全支持要求的數(shù)據(jù)。
例如，綁定的模擬數(shù)據(jù)有利于確認(rèn)數(shù)據(jù)域足夠長并能夠適合提供的可利用的空間。開發(fā)者還可以根據(jù)綁定的數(shù)據(jù)元素來加強(qiáng)客戶端的驗證標(biāo)準(zhǔn)。
最后，這些界面組合到一起就構(gòu)成了一個有功能的、模擬的應(yīng)用程序版本。
提供一個精確的API你已經(jīng)設(shè)計的這些從本質(zhì)上來說是應(yīng)用程序?qū)⒁玫降腁PI。你現(xiàn)在知道應(yīng)用程序肯定會讀取的數(shù)據(jù)域，將要傳輸?shù)臄?shù)據(jù)域，以及哪一部分的業(yè)務(wù)邏輯會在服務(wù)器層和客戶層。數(shù)據(jù)服務(wù)（Data Services）現(xiàn)在開發(fā)完成了，它對靜態(tài)模擬數(shù)據(jù)來說是多態(tài)的。這確保了返回到RIA的數(shù)據(jù)的格式和應(yīng)用程序顯示數(shù)據(jù)的格式很相似。
我們不能忘記這種難以置信的重要的優(yōu)勢。導(dǎo)致RIAs表現(xiàn)問題的最大原因之一就是程序必須自己把從數(shù)據(jù)服務(wù)（Data Services）返回的數(shù)據(jù)處理成適合用戶體驗的格式。這是“從后往前”設(shè)計中最大的缺陷之一。當(dāng)你在用戶體驗之前設(shè)計服務(wù)（services）和API的時候，不可能保證二者之間的精度。在“從前往后”這種方式中，Data service 和 API 只會在RIA需要他們的時候才創(chuàng)建，這就避免了二次開發(fā)從而有效地縮短了開發(fā)時間。
把真正的數(shù)據(jù)綁定到用戶界面隨著每個data service逐漸開發(fā)完成，用戶界面的綁定也從靜態(tài)數(shù)據(jù)轉(zhuǎn)變?yōu)檫B接到真正的data services。因為我們已經(jīng)確保了兩者之間的兼容性，所以程序完工了。
“從前往后”方式的優(yōu)點(diǎn)用“從前往后”方式開發(fā)應(yīng)用程序不只是理論上的練習(xí)。它為你和你的用戶在以下三個方面提供了很高的價值：
更好的需求收集：用戶不知道你們開發(fā)者的語言。用戶不知道你們?nèi)绾伍_發(fā)他們的應(yīng)用程序，坦白地說，他們也不關(guān)心那個。然而如果他們能看到你創(chuàng)建的應(yīng)用程序原型，他們會很快地加入進(jìn)來，并告訴你這個應(yīng)用程序?qū)⒁鍪裁床⑶以鯓尤プ觥?br>更快的開發(fā)和回饋：用戶不能接觸到一個引擎并且與它交互。他們不能演示一個API。然而如果你先開發(fā)連接靜態(tài)數(shù)據(jù)的用戶界面的話，用戶便可以向他們的客戶展示程序去收集回饋。這甚至可以讓你的用戶在開發(fā)結(jié)束之前就開始賣出他們的產(chǎn)品。
用戶成為擁護(hù)者，而不再是對手：用戶可能認(rèn)為你不理解他的需求、一直延誤，或者你從未在最后給出它們真正想要的程序。通過“從前往后”的開發(fā)方式，你可以通過讓用戶參與到實際開發(fā)來轉(zhuǎn)變這種關(guān)系，這樣可以讓他們感受到你作為一個開發(fā)者所感受到的同樣的工作情緒。很快他們就會成為你最大的擁護(hù)者。
接下來干什么怎樣在實際中把這些觀點(diǎn)應(yīng)用到開發(fā)你自己的RIA當(dāng)中？在接下來的四部分中，我們將回顧這種方式并詳細(xì)討論一下Flex 2.0 Beta如何進(jìn)行RIA開發(fā)以及——概括地說——“從前往后”開發(fā)，尤其是如何進(jìn)行讓你的應(yīng)用程序變得強(qiáng)大的開發(fā)。
你將會通過代碼實例和屏幕截圖來學(xué)習(xí)這些特性，它將會幫助你盡可能簡單地適應(yīng)你的開發(fā)方式。在最后，你將會得到使用Flex 2.0進(jìn)行開發(fā)所需要的一切工具。
