序文
開発モデルのフロントエンドとバックエンドを分離するためにNodeを使用することは、いくつかのパフォーマンスと開発プロセスの利点をもたらしますが（参照）、多くの課題にも直面しています。淘宝網の複雑なビジネスと技術アーキテクチャでは、バックエンドはインフラストラクチャを構築するためにJavaに依存しなければならず、同時にフロントエンドが使用するために関連するビジネスインタフェースを提供しなければなりません。全環境におけるNodeの最も重要な仕事の1つは、フロントエンドがページレンダリングを行うためにデータを統合するのを容易にするために、これらのビジネスインタフェースをプロキシすることです。フロントエンドとバックエンドの開発を分離した後でもシームレスにプロセスを接続できるように、プロキシ作業をどのようにうまく行うかは、考慮すべき問題です。本稿では、この問題について議論し、解決策を提案します。
バックエンドは様々なインタフェースを提供するため、開発者は様々な方法でこれらのインタフェースにアクセスするNodeコードを書くこともできます。インターフェースにアクセスし使用するための統一されたアーキテクチャがない場合、以下のような問題が発生する可能性があります：
1.各開発者が独自のコードスタイルでインターフェイスアクセスコードを記述するため、プロジェクトカタログやコーディングスタイルが混乱し、保守が比較的困難になります。
2.各開発者は自分自身のモックデータメソッドを記述し、開発完了後、モックを削除するためにコードを手作業で修正する必要があります。
3.各開発者は、インターフェースの異なる環境間の切り替えを可能にするために、別々の設定ファイルを保持することができます。
4.データインターフェースの呼び出しは、個々のビジネスモデルで簡単に再利用できません。
5.データインタフェースを記述するための規約がコード全体に散らばっており、バックエンドの担当者によって合意されたインタフェース文書と一致しない可能性があります。
6.プロジェクト全体が別々に開発された後では、インターフェイスやリグレッションのテストのコストは高いままであり、各インターフェイスのプロバイダーとユーザーが関与する必要があります。
フレームワークは、プロジェクトが依存するすべての外部インタフェースを記述し、統一された方法でそれらを管理し、柔軟なインタフェースモデリングと呼び出しを提供するメカニズムを提供します。ModelProxyは、このような要件を満たすための軽量なフレームワークであり、Midway Frameworkのコアコンポーネントの一つです。ModelProxyを使うことで、以下のような利点があります：
1.統一された方法で書かれたインターフェイスのアクセスコードの異なる開発者は、明確な意味は、メンテナンスの難しさを軽減します。
3.オンライン環境、デイリー環境、プレリリース環境の切り替えは非常に簡単です。
4.river-mockmockjsモックエンジンを内蔵しており、モックデータを提供するのが非常に便利です。
5.インターフェイスの依存関係の記述を統一的に管理し、さまざまなコードに分散させないために、インターフェイス設定ファイルを使用します。
6.ブラウザ側の共有モデルをサポートし、ブラウザ側は、フロントエンドのデータレンダリングを行うためにそれを使用することができます。プロキシ処理全体はブラウザに対して透過的です。
7.インターフェイスプロファイル自体は構造化された記述文書であり、riverツールのコレクションを使用して文書を自動的に生成することができます。それはまた、関連する自動化されたインターフェイステストを行うために使用することができます。
上図では、開発者はまず、プロジェクトが依存するすべてのバックエンドインターフェースの説明を、指定されたjsonフォーマットでinterface.json設定ファイルに記述する必要があります。必要に応じて、各インターフェイスのルールファイル、つまり図のインターフェイスルールの部分を記述する必要があります。このルールファイルは、開発段階でデータをモックしたり、チューニング段階でRiverツールセットを使用してインターフェースを検証するために使用します。ルールファイルの内容は、使用するモックエンジンによって異なります。設定が完了したら、ニーズに合わせてコード内に独自のビジネスモデルを作成できます。
簡単な例を挙げましょう：
例1
- Step *** プロジェクトのディレクトリにインターフェース設定ファイルinterface.jsonを作成し、メインの検索インターフェースのjson定義を追加します。
{
"title": "pad淘宝網プロジェクトデータインタフェース収集定義 ",
"version": "1.0.0",
"engine": "mockjs",
"rulebase": "./interfaceRules/",
"status": "online",
"interfaces": [ {
"name": "メイン検索インターフェース",
"id": "Search.getItems",
"urls": {
"online": "http://...com/client/.do"
}
} ]
}
- ステップ2 コードでモデルを作成し、使用します
// モジュールの導入
var ModelProxy = require( 'modelproxy' );
// 全局初始化引入接口配置文件 （注意：初始化工作有且只有一次）
ModelProxy.init( './interface.json' );
// 创建model 更多创建模式请参后文
var searchModel = new ModelProxy( {
searchItems: 'Search.getItems' // カスタムメソッド名: 設定ファイルで定義されたインターフェースID
} );
// 使用model, 注意: メソッドの呼び出しに必要なパラメータは、実際のインターフェースに必要なパラメータである。
searchModel.searchItems( { q: 'iphone6' } )
// !注意 必须调用 done 方法指定回调函数，来取得上面异步调用searchItems获得的数据!
.done( function( data ) {
console.log( data );
} )
.error( function( err ) {
console.log( err );
} );
#p#
ModelProxyの豊かさは、必要なビジネスモデルを作成するための様々な形式のプロファイルのサポートにあります：
- インターフェイスIDで作成 > 生成されたオブジェクトは、ID*** '.番号の後に単語を続けたものをメソッド名とします。
ModelProxy.create( 'Search.getItem' );
キー・バリューJSONオブジェクトの使用 > カスタムメソッド名：インターフェースID
ModelProxy.create( {
getName: 'Session.getUserName',
getMyCarts: 'Cart.getCarts'
} );
- 配列形式を使用します。 記号の後の単語がメソッド名として使われます。
ModelProxy.create( [ 'Cart.getItem', 'Search.getItem', 'Search.suggest', 'Session.User.getName' ] );
- 接頭辞形式 > 接頭辞を満たすすべてのインターフェースIDがオブジェクトに導入され、後半がメソッド名となります。
ModelProxy.create( 'Search.*' );
同時に、これらのモデルを使うことで、マージリクエストや依存関係のリクエスト、関連するテンプレートのレンダリングを簡単に実装することができます。
例2 連結リクエスト
var model = new ModelProxy( 'Search.*' );
// 合并请求 (下面调用的model方法除done之外，皆为配置接口id时指定)
model.suggest( { q: ' } )
.list( { keyword: 'iphone6' } )
.getNav( { key: '人気アパレルの } )
.done( function( data1, data2, data3 ) {
// パラメータの順序は、メソッド呼び出しの順序と一致している。
console.log( data1, data2, data3 );
} );
例3 リクエストへの依存
var model = new ModelProxy( {
getUser: 'Session.getUser',
getMyOrderList: 'Order.getOrder'
} );
// 最初にユーザーIDを取得し、次にID番号に基づいて注文リストを取得する。
model.getUser( { sid: 'fdkaldjfgsakls0322yf8' } )
.done( function( data ) {
var uid = data.uid;
// セカンダリデータリクエストの依存性***サブ取得ID番号
this.getMyOrderList( { id: uid } )
.done( function( data ) {
console.log( data );
} );
} );
また、ModelProxyはNode側だけでなくブラウザ側でも利用することができます。公式パッケージで提供されているmodelproxy-client.jsをページ内に導入するだけです。
例 4 ブラウザ側での ModelProxy の使用
<!-- modelproxyモジュールが導入され、モジュール自体はKISSYによってカプセル化された標準モジュールである。>
<script src="modelproxy-client.js" ></script>
<script type="text/javascript">
KISSY.use( "modelproxy", function( S, ModelProxy ) {
// !ステップ2で設定したインターセプトパスと同じベースパスを設定する。!
// また、グローバルコンフィギュレーションは一度だけである！
ModelProxy.configBase( '/model/' );
// モデルの作成
var searchModel = ModelProxy.create( 'Search.*' );
searchModel
.list( { q: 'ihpone6' } )
.list( { q: 'パンチ } )
.suggest( { q: 'i' } )
.getNav( { q: 'スケートボードの } )
.done( function( data1, data2, data3, data4 ) {
console.log( {
"list_ihpone6": data1,
"list_パンチ": data2,
"suggest_i": data3,
"getNav_ : data4
} );
} );
} );
</script>
同時に、ModelProxyはMidwayのもう一つのコアコンポーネントであるMidway-XTPLと一緒に使うことで、ブラウザ側とサーバ側の両方でデータとテンプレートの完全な共有、および関連するレンダリング処理を実現することができます。ModelProxyの詳細なチュートリアルとドキュメントは/xyをご覧ください。
概要
設定可能な軽量フレームワークにModelProxyは、フレンドリーなインターフェイスモデルのアセンブリを提供し、使用すると同時に、インターフェイスの使用仕様の問題のフロントエンドとバックエンドの開発モードの分離に良い解決策が存在します。プロジェクト全体の開発プロセスでは、インターフェイスは常に唯一の時間の説明を定義する必要がある、フロントエンドの開発者が参照することができます、自動的にドキュメントを生成するために川のツールを使用している間、バックエンドの開発者との契約の形成、および関連する自動テストを行うには、大幅にソフトウェアエンジニアリングの開発プロセス全体を最適化します。
