鄭慶華，史元超，李文寶

（1.哈爾濱鐵路局 信息技術(shù)所，黑龍江 哈爾濱 150006；2.中國(guó)鐵路總公司 營(yíng)運(yùn)部，北京 100844；3.中國(guó)鐵路信息技術(shù)中心 信息工程部，北京 100038）

鐵路零散快運(yùn) APP架構(gòu)的探討

鄭慶華1，史元超2，李文寶3

（1.哈爾濱鐵路局 信息技術(shù)所，黑龍江 哈爾濱 150006；2.中國(guó)鐵路總公司 營(yíng)運(yùn)部，北京 100844；3.中國(guó)鐵路信息技術(shù)中心 信息工程部，北京 100038）

隨著智能終端快速發(fā)展并被廣泛應(yīng)用，APP技術(shù)應(yīng)用和推廣在鐵路現(xiàn)代物流業(yè)務(wù)發(fā)展中突顯優(yōu)勢(shì)地位。在闡述鐵路零散貨物快運(yùn)業(yè)務(wù)流程的基礎(chǔ)上，分析MVC模式、MVP模式、MVVM模式3類主要架構(gòu)模式的特征。根據(jù)鐵路零散貨物快運(yùn)平臺(tái)總體要求，從信息架構(gòu)的概念和構(gòu)建、任務(wù)分析及使用方法、APP架構(gòu)模式選擇等方面設(shè)計(jì)鐵路零散快運(yùn)APP架構(gòu)，闡明鐵路零散快運(yùn)APP采用MVP架構(gòu)的優(yōu)勢(shì)。

鐵路物流；零散貨物快運(yùn)；架構(gòu)；APP；MVP

我國(guó)鐵路貨運(yùn)物流行業(yè)市場(chǎng)前景廣闊，但信息化水平相對(duì)滯后。目前，隨著手機(jī)等智能移動(dòng)設(shè)備應(yīng)用的大眾化，移動(dòng)互聯(lián)網(wǎng)不斷沖擊著人們的傳統(tǒng)觀念，貨運(yùn)物流行業(yè)也不例外。21 世紀(jì)是互聯(lián)網(wǎng)經(jīng)濟(jì)時(shí)代，是信息快速傳播、第一時(shí)間分享與知曉信息的時(shí)代，智能手機(jī)的普及使手機(jī)客戶端的應(yīng)用和開(kāi)發(fā)越來(lái)越廣泛。國(guó)家高度重視互聯(lián)網(wǎng)應(yīng)用和推廣，國(guó)務(wù)院于 2015 年 7 月頒發(fā)了《“互聯(lián)網(wǎng)+”行動(dòng)的指導(dǎo)意見(jiàn)》[1]；隨后商務(wù)部頒發(fā)了《“互聯(lián)網(wǎng)+流通”行動(dòng)計(jì)劃》，明確提出加快產(chǎn)品流通過(guò)程中互聯(lián)網(wǎng)設(shè)施設(shè)備建設(shè)[2]。APP 技術(shù)主要實(shí)現(xiàn)手機(jī)連接到互聯(lián)網(wǎng)業(yè)務(wù)的應(yīng)用程序服務(wù)，隨著技術(shù)發(fā)展和廣泛應(yīng)用，其在鐵路貨運(yùn)的應(yīng)用逐步受到重視。開(kāi)發(fā)鐵路零散快運(yùn)APP，可以讓貨主了解第一時(shí)間的資訊及享受方便快捷的服務(wù)[3]。鐵路零散快運(yùn) APP 的誕生是順應(yīng)信息時(shí)代潮流、滿足移動(dòng)互聯(lián)網(wǎng)需求的產(chǎn)物，也是國(guó)家“互聯(lián)網(wǎng)+”戰(zhàn)略的應(yīng)用。通過(guò) APP 技術(shù)可以實(shí)現(xiàn)鐵路零散貨物的快捷運(yùn)輸，為客戶提供便捷、準(zhǔn)時(shí)、高效的物流服務(wù)。

1 鐵路零散快運(yùn)APP架構(gòu)分析

1.1 鐵路零散快運(yùn)業(yè)務(wù)流程分析

鐵路零散快運(yùn) APP 可以幫助企業(yè)和貨主簡(jiǎn)化操作程序、節(jié)省人力物力、降低成本，提升鐵路服務(wù)質(zhì)量。鐵路零散貨物快運(yùn)業(yè)務(wù)流程如圖 1 所示 。

1.2 APP 架構(gòu)

軟件架構(gòu)的作用是全面考慮產(chǎn)品從需求到設(shè)計(jì)的每個(gè)細(xì)節(jié)，使設(shè)計(jì)的項(xiàng)目效率高、開(kāi)發(fā)容易、維護(hù)方便、升級(jí)簡(jiǎn)單。衡量 APP 架構(gòu)的重要標(biāo)準(zhǔn)是考慮APP 適用于團(tuán)隊(duì)及業(yè)務(wù)規(guī)模、產(chǎn)品/商業(yè)發(fā)展方向。如果團(tuán)隊(duì)規(guī)模擴(kuò)大，而擴(kuò)展性不足、維護(hù)性崩壞、性能受到影響，就必須對(duì) APP 進(jìn)行重構(gòu)。因此，應(yīng)充分分析 APP 架構(gòu)模式的主要特征，對(duì) APP 架構(gòu)進(jìn)行設(shè)計(jì)。APP 架構(gòu)模式主要有以下 3 類。

1.2.1 MVC模式

MVC 是目前主流的系統(tǒng)設(shè)計(jì)模式之一，將模型 (Model) 與視圖 (View) 和控制器 (Controller) 三者分離，分別設(shè)計(jì)使系統(tǒng)具有低耦合、高內(nèi)聚特性，便于程序的設(shè)計(jì)和后期升級(jí)、維護(hù)。MVC 設(shè)計(jì)將 3 種不同層次的系統(tǒng)設(shè)計(jì)人員結(jié)合到一起，分析師設(shè)計(jì)系統(tǒng)模型、設(shè)計(jì)師設(shè)計(jì)系統(tǒng)控制流程、界面設(shè)計(jì)師負(fù)責(zé)設(shè)計(jì)系統(tǒng)人機(jī)交互界面。作為一種軟件設(shè)計(jì)典范，MVC 將業(yè)務(wù)邏輯、數(shù)據(jù)與界面設(shè)計(jì)分離，業(yè)務(wù)邏輯集中到一個(gè)部件，在后續(xù)完善、改進(jìn)個(gè)性化設(shè)計(jì)界面和人機(jī)交互控制時(shí)，不再需要重新修改業(yè)務(wù)邏輯部分。MVC 被廣泛應(yīng)用于映射輸入、處理、輸出功能在一個(gè)邏輯的圖形化用戶界面的結(jié)構(gòu)中，MVC 模式各部分關(guān)系和功能如圖 2 所示。

圖 2 MVC 模式各部分的關(guān)系和功能

1.2.2 MVP模式

MVP (Model View Presenter)[4]模式由 MVC 模式演變而來(lái)，MVP 模式將 MVC 模式中的 Controller 修改為 Presenter，同時(shí)改變了通信方向。通常的 MVP模式中，View 一般由表示器進(jìn)行創(chuàng)建，用戶界面(UI)接收使用者的命令，不對(duì)使用者輸入作邏輯處理，而是將使用者錄入的信息發(fā)送給表示器。一般 1 個(gè) View對(duì)照 1 個(gè)表示器，表示器含蓋了絕大多數(shù)的處理邏輯，用來(lái)解析 View，與模型結(jié)合以獲取或變更數(shù)據(jù)等。

擠壓法是一種新興的微膠囊技術(shù),相對(duì)其他微膠囊制作方法有自身優(yōu)勢(shì),它是在低溫下加工生產(chǎn)微膠囊的技術(shù),表面孔面積較小,能防止精油揮發(fā)和氧氣進(jìn)入; 表面油量少,貨架壽命長(zhǎng); 操作溫度低,對(duì)風(fēng)味物質(zhì)損害小。因此有必要在擠壓法制備精油微膠囊工藝方面進(jìn)行深入研究。

MVP 模式和 MVC 模式的基本思想是，Controller/Presenter 的工作是處理邏輯，Model 供給業(yè)務(wù)信息，View 用來(lái)面向客戶。在 MVP 模式中View 與 Model 間進(jìn)行的通信是由 Presenter 完成的，并不與 Model 直接交流，全部邏輯處理過(guò)程都是由Presenter 獨(dú)自完成。而在 MVC 模式中，數(shù)據(jù)的取得不依靠 Controller，而是從 Model 獲取 View 所需信息。MVC 模式可以同時(shí)有多個(gè) View 將同一個(gè) Model的數(shù)據(jù)以不同的形式顯示出來(lái)，因而在 MVC 模式中，Model 不依賴于 View，但 View 依賴于 Model 。因?yàn)?View 與 Model 存在業(yè)務(wù)邏輯，如果更改 View 則必須更改 Model 的一些代碼，使這些代碼無(wú)法重用。MVP 模式的改善在于 View 與 Model 的完全隔離。

1.2.3 MVVM 模式

MVVM (Model View View Model) 模式是結(jié)合MVP 和 WPF (Windows Presentation Foundation) 之后產(chǎn)生的更具優(yōu)勢(shì)和擴(kuò)展性的框架[5]，它將 MVP 和WPF 的自定義數(shù)據(jù)結(jié)構(gòu)、自定義命令綁定等獨(dú)特技術(shù)融合，更好地滿足客戶多變的需求。MVVM 模式主要目的是分離 View 和 Model，同時(shí)具有低耦合、可重用性、獨(dú)立開(kāi)發(fā)、可測(cè)試優(yōu)點(diǎn)。

1.2.4 模式比較

MVP 模式和 MVC 模式的關(guān)系不是相互獨(dú)立而是相互依存、相互借鑒，是 MVP 模式的展示層與Presenter 層的關(guān)系，即編寫界面的開(kāi)發(fā)人員在展示層留下部分邏輯代碼，用來(lái)將展示層與 Presenter 相關(guān)聯(lián)。View 在 MVVM 模式中完全釋放，使用通用的標(biāo)記工具 XAML 使 View Model 的自定義數(shù)據(jù)和命令分別與 View 關(guān)聯(lián)。通過(guò) MVVM 模式構(gòu)建的架構(gòu)，應(yīng)用開(kāi)發(fā)人員能夠更容易地繪制應(yīng)用程序。構(gòu)建過(guò)程中應(yīng)注意 MVVM 的語(yǔ)言限制在 WPF 和 Silverlight。MVC 模式、MVP 模式、MVVM 模式如圖 3 所示。

2 鐵路零散貨物快運(yùn) APP 架構(gòu)的設(shè)計(jì)

圖 3 MVC 模式、MVP 模式、MVVM 模式

鐵路零散貨物快運(yùn)平臺(tái)的總體要求：以客戶需求為導(dǎo)向，以標(biāo)準(zhǔn)化、信息化為支撐，以完善作業(yè)條件、規(guī)范組織管理、健全配套機(jī)制為重點(diǎn)，以調(diào)結(jié)構(gòu)、提質(zhì)量、增運(yùn)量為目標(biāo)，發(fā)揮鐵路長(zhǎng)距離、覆蓋廣的優(yōu)勢(shì)，為客戶提供便捷、準(zhǔn)時(shí)、高效的一體化物流服務(wù)，融入客戶產(chǎn)業(yè)鏈、供應(yīng)鏈、物流鏈，實(shí)現(xiàn)貨運(yùn)作業(yè)快捷和客戶受理便捷。面向不同使用人群，鐵路零散貨物快運(yùn) APP 針對(duì)不同人群設(shè)置不同功能模塊，開(kāi)發(fā)站內(nèi)貨運(yùn)員手持機(jī)應(yīng)用、列車長(zhǎng)手持機(jī)應(yīng)用、接取送達(dá)人員手持機(jī)應(yīng)用及 95306 客戶手持機(jī)移動(dòng)應(yīng)用。目前 APP 應(yīng)用主要分為 2 大類別：瀏覽類、操作型應(yīng)用。瀏覽類應(yīng)用模型的構(gòu)建通過(guò)核心展示層架構(gòu)的方法從內(nèi)容瀏覽、信息展示入手，對(duì)所要展示的內(nèi)容、信息進(jìn)行分類整合；操作型應(yīng)用通過(guò)業(yè)務(wù)分析法，將業(yè)務(wù)由上到下逐級(jí)分析成使用者能夠通過(guò)操作處理業(yè)務(wù)的功能模塊。

2.1 信息架構(gòu)

信息架構(gòu)是一種對(duì)信息整合分類的方法[6]，使各種信息有序、高效地展示在任何用戶可能用到的地方。鐵路零散貨物快運(yùn)數(shù)據(jù)是海量數(shù)據(jù)，對(duì)其數(shù)據(jù)信息進(jìn)行架構(gòu)需要有基于 DBA (Database Administrator，數(shù)據(jù)庫(kù)管理員) 能力的專業(yè)數(shù)據(jù)分析師從多角度、多層面進(jìn)行分析整理。但是，現(xiàn)實(shí)的手機(jī)應(yīng)用設(shè)計(jì)中，數(shù)據(jù)信息簡(jiǎn)單，對(duì)于這類信息有 3 種分析方法：信息結(jié)構(gòu)、邏輯樹(shù)結(jié)構(gòu)、卡片分類方法。

（2）邏輯樹(shù)結(jié)構(gòu)是依照人們從古至今生活經(jīng)驗(yàn)中慢慢被認(rèn)可的邏輯結(jié)構(gòu)，將信息按照樹(shù)狀邏輯由大到小、由總到分等情況進(jìn)行排布。

（3）卡片分類是人們對(duì)很多目前還呈現(xiàn)出動(dòng)態(tài)變化的信息，按照統(tǒng)計(jì)分類的方法進(jìn)行歸納總結(jié)。

經(jīng)分析，鐵路零散貨物快運(yùn)的業(yè)務(wù)特點(diǎn)適合于卡片分類。

2.2 任務(wù)分析及使用方法

任務(wù)分析是指開(kāi)發(fā)人員對(duì)某一特定需求下的目標(biāo)進(jìn)行深入了解的過(guò)程，過(guò)程中開(kāi)發(fā)人員將通過(guò)各種方式方法進(jìn)行分析整合或信息處理，通過(guò)了解用戶的需求，用戶會(huì)根據(jù)自己的經(jīng)驗(yàn)或?qū)嶋H需要、看到和聽(tīng)到的類似業(yè)務(wù)，確定自己要實(shí)現(xiàn)的目標(biāo)；開(kāi)發(fā)人員應(yīng)根據(jù)用戶目錄逐級(jí)分析需求，再分解為若干功能模塊，功能模塊由多個(gè)子功能組成，每個(gè)子功能再分為若干操作。鐵路零散貨物快運(yùn) APP 的任務(wù)分析，要求開(kāi)發(fā)人員了解和掌握需要達(dá)到的目標(biāo)、實(shí)現(xiàn)的功能、處理的信息，以及信息傳遞的方向和狀態(tài)，APP 在整個(gè)應(yīng)用架構(gòu)中應(yīng)滿足鐵路零散貨物快運(yùn)用戶最迫切的需求和目標(biāo)，使開(kāi)發(fā)人員可以估算開(kāi)發(fā)周期、制訂開(kāi)發(fā)計(jì)劃，并且詳細(xì)設(shè)計(jì)的開(kāi)發(fā)單元。

2.3 APP 架構(gòu)模式選擇

MVP 是比較流行的基礎(chǔ)架構(gòu)模式，是鐵路零散貨物快運(yùn) APP 理想的架構(gòu)模式選擇。在 MVP 模式中，View 與 Model 并不直接交互，MVP 的 Presenter是框架的控制者，承擔(dān)了大量的邏輯操作。MVP 的變種有很多，其中使用最廣泛的是 Passive View 模式，即被動(dòng) View。在這種模式下，整個(gè)框架內(nèi)部模塊之間的邏輯操作均由 Presenter 控制，View 僅僅是整個(gè)操作的匯報(bào)者和結(jié)果接收者，Model 根據(jù) Presenter 的單向調(diào)用返回?cái)?shù)據(jù)，View 與 Model 的耦合性更低，降低了 Presenter 對(duì) View 的依賴，實(shí)現(xiàn)了關(guān)注點(diǎn)分離的初衷，方便開(kāi)發(fā)人員的編碼和測(cè)試工作。MVP 的使用大大提高系統(tǒng)的模塊化、服務(wù)化趨勢(shì)，使系統(tǒng)的構(gòu)建更簡(jiǎn)潔，開(kāi)發(fā)人員能夠更靈活地進(jìn)行編碼及業(yè)務(wù)邏輯的可重用性。

具體到 Android APP 中，一般將 APP 根據(jù)程序的結(jié)構(gòu)進(jìn)行縱向劃分，對(duì)應(yīng) MVP 分別為模型層，UI層和邏輯層。UI 層一般包括 Activity，F(xiàn)ragment，Adapter 等直接與 UI 相關(guān)的類，UI 層的 Activity 在啟動(dòng)后實(shí)例化相應(yīng)的 Presenter，App 的控制權(quán)后移，由 UI 轉(zhuǎn)移到 Presenter，兩者之間的通信通過(guò)BroadCast，Handler 或接口完成，只傳遞事件和結(jié)果。例如，UI 層通知邏輯層用戶點(diǎn)擊了一個(gè) Button，邏輯層決定應(yīng)用什么行為進(jìn)行響應(yīng)，該找哪個(gè)模型去完成，最后邏輯層將完成的結(jié)果更新至UI 層。

模型層 (Model) 中的整體代碼量是最大的，一般由大量的 Package 組成，針對(duì)這部分需要在程序設(shè)計(jì)中做好模塊的劃分，進(jìn)行接口隔離，在內(nèi)部進(jìn)行分層。

強(qiáng)化 Presenter 的作用，將所有邏輯操作都放在Presenter 內(nèi)也容易造成 Presenter 內(nèi)的代碼量過(guò)大，因而應(yīng)在 UI 層與 Presenter 之間設(shè)置中介者 Mediator，將如數(shù)據(jù)校驗(yàn)、組裝在內(nèi)的輕量級(jí)邏輯操作放在Mediator中；在 Presenter 與 Model 間使用代理Proxy。通過(guò)上述處理，分擔(dān)部分 Presenter 的邏輯操作，但整體框架還由 Presenter 控制，Mediator 和Proxy 不是必需的，只在 Presenter 負(fù)擔(dān)過(guò)大時(shí)用。鐵路零散貨物快運(yùn) APP 架構(gòu)如圖 4 所示。

在 MVP 中，Model 和 View 被 Presenter 隔離，Presenter 為業(yè)務(wù)邏輯處理中心，不直接關(guān)聯(lián)相應(yīng)的View，而是通過(guò)接口注冊(cè)的后接口對(duì) View 進(jìn)行交互處理，既達(dá)到了 Model 與 View 的分離，也使 View 具有充分的可復(fù)用性。為了方便開(kāi)發(fā)人員模擬開(kāi)發(fā)過(guò)程中的業(yè)務(wù)或操作，開(kāi)發(fā)單獨(dú)的 View 或?qū)?Presenter 進(jìn)行變更，而不影響 Presenter。

鐵路零散貨物快運(yùn) APP 采用 MVP 架構(gòu)的優(yōu)勢(shì)在于： 用戶界面與業(yè)務(wù)邏輯充分分離，架構(gòu)更靈活、編碼更簡(jiǎn)單更單一；視圖和業(yè)務(wù)邏輯的復(fù)用可以無(wú)縫替換；通過(guò)設(shè)計(jì)使程序模塊化，做到模塊內(nèi)部的高聚合和模塊之間的低耦合；程序在開(kāi)發(fā)的過(guò)程中，開(kāi)發(fā)人員只需要專注于一點(diǎn)，提高程序開(kāi)發(fā)的效率，并且更容易進(jìn)行后續(xù)的測(cè)試及定位。

圖 4 鐵路零散貨物快運(yùn) APP 架構(gòu)

3 結(jié)束語(yǔ)

移動(dòng)應(yīng)用架構(gòu)選擇必須充分認(rèn)識(shí)軟件適用人群的特性、業(yè)務(wù)需求的特點(diǎn)，靈活地選擇產(chǎn)品架構(gòu)，才能更好地平衡軟件整體、更好推廣使用。2015 年 6 月鐵路零散貨物快運(yùn) APP 平臺(tái)投產(chǎn)以來(lái)，應(yīng)用于貨運(yùn)員、列車長(zhǎng)、司機(jī)配送員等崗位，已經(jīng)在鐵路物流服務(wù)中發(fā)揮了積極作用，是鐵路物流服務(wù)從“站到站”運(yùn)輸向“門到門”物流配送轉(zhuǎn)變的信息化工具，是精細(xì)化管理運(yùn)輸組織作業(yè)的手段。鐵路從運(yùn)輸企業(yè)向現(xiàn)代化物流企業(yè)轉(zhuǎn)型面臨挑戰(zhàn)，零散貨物快運(yùn)業(yè)務(wù)只是鐵路眾多運(yùn)輸業(yè)務(wù)中的一種，還有整車、零擔(dān)、集裝箱、批量零散等更加復(fù)雜的業(yè)務(wù)，鐵路零散貨物快運(yùn) APP 為鐵路信息化升級(jí)改造提供了條件。

[1]中華人民共和國(guó)國(guó)務(wù)院.國(guó)務(wù)院關(guān)于積極推進(jìn)“互聯(lián)網(wǎng)+”行動(dòng)的指導(dǎo)意見(jiàn)[S].北京：中華人民共和國(guó)國(guó)務(wù)院，2015.

[2]中華人民共和國(guó)商務(wù)部.“互聯(lián)網(wǎng)+流通”行動(dòng)計(jì)劃[S].北京：中華人民共和國(guó)商務(wù)部，2015.

[3]中國(guó)鐵路總公司.關(guān)于進(jìn)一步加強(qiáng)零散貨物快運(yùn)的實(shí)施意見(jiàn)[S].北京：中國(guó)鐵路總公司，2015.

[4]李礁.淺議MVP模式在Windows項(xiàng)目中的應(yīng)用[J].信息通信，2011，10(4)：99-102.

[5]AndersonC.TheModel-View-ViewModel(MVVM)DesignPatternproBusinessApplicationswithSilverlight[J].2010，33(1)：373-402.

[6]李和中，陳芳.基于云計(jì)算信息架構(gòu)的云政府服務(wù)[J].中國(guó)行政管理，2012，29(3)：22-25.

責(zé)任編輯：何 瑩

1004-2024(2015)10-0032-06

：TP399：U294.4

：B

10.16669/j.cnki.issn.1004-2024.2015.10.08

2015-09-25