ホームページ > 記事 > ウェブフロントエンド > NodeJSによるフロントエンドとバックエンド分離の思考と実践(3) 軽量インターフェース構成モデリングframework_node.js
NodeJSによるフロントエンドとバックエンド分離の思考と実践(3) 軽量インターフェース構成モデリングframework_node.js
- WBOYオリジナル
- 2016-05-16 16:35:211134ブラウズ
はじめに
Node を使用してフロントエンドとバックエンドを分離する開発モデルは、パフォーマンスと開発プロセスにおいていくつかの利点をもたらしますが、多くの課題にも直面しています。 Taobao の複雑なビジネスおよび技術アーキテクチャでは、バックエンドは Java に依存してインフラストラクチャを構築し、フロントエンドが使用する関連ビジネス インターフェイスを提供する必要があります。環境全体における Node の最も重要なタスクの 1 つは、これらのビジネス インターフェイスをプロキシして、フロントエンド (ノード側とブラウザ側) がページ レンダリング用のデータを統合できるようにすることです。フロントエンド開発とバックエンド開発を分離した後も、プロセスをシームレスに接続できるように、代理店業務をどのようにうまく機能させるかは、検討する必要がある課題です。この記事では、この問題について説明し、解決策を提案します。
バックエンドによって提供されるインターフェースは多様である可能性があるため、開発者がノード側のコードを作成するときにこれらのインターフェースにアクセスするためのさまざまな方法も存在する可能性があります。インターフェースのアクセス方法や使用方法に関して統一したアーキテクチャを実装しないと、次のような問題が発生します。
1. 各開発者は独自のコーディング スタイルを使用してインターフェイス アクセス コードを作成するため、プロジェクト ディレクトリとコーディング スタイルに混乱が生じ、メンテナンスが比較的困難になります。
2. 各開発者は独自のモック データ メソッドを作成し、開発後にコードを手動で変更してモックを削除する必要があります。
3. 各開発者は、インターフェースの異なる環境切り替え (毎日、プレリリース、オンライン) を実装するために、いくつかの構成ファイルを維持する場合があります。
4. データインターフェース呼び出しメソッドは、さまざまなビジネスモデルで簡単に再利用できません。
5. データ インターフェイスの記述がコードの隅々に散在しており、バックエンド担当者が合意したインターフェイス文書と矛盾している可能性があります。
6. プロジェクト全体が個別に開発された後でも、インターフェースの共同デバッグやテスト回帰のコストは依然として非常に高く、すべてのインターフェースプロバイダーとユーザーが関与する必要があります。
したがって、フレームワークによって提供されるメカニズムを使用して、プロジェクトが依存するすべての外部インターフェイスを記述し、それらを均一に管理し、柔軟なインターフェイスのモデリングと呼び出しメソッドを提供し、便利なオンライン環境と運用環境を提供するようなフレームワークが欲しいと考えています。スイッチング方式により、フロントエンド開発とバックエンド開発のシームレスな統合が可能になります。 ModelProxy は、このような要件を満たす軽量フレームワークであり、Midway Framework のコア コンポーネントの 1 つであり、単独で使用することもできます。 ModelProxy を使用すると、次のような利点があります:
2. フレームワーク内ではファクトリーシングルトンモードが採用されており、インターフェース構成を一度実現すれば複数回再利用できます。また、開発者は独自のビジネス モデル (依存関係の注入) を自由にカスタマイズして組み立てることができます。
3. オンライン、日常、リリース前の環境を切り替えるのに非常に便利です。
4.river-mockやmockjsなどの組み込みモックエンジンにより、モックデータを提供するのが非常に便利です。
5. インターフェイス設定ファイルを使用して、インターフェイスの依存関係の記述を統一的に管理し、さまざまなコード間で分散することを避けます。
6. ブラウザ側共有モデルをサポートし、ブラウザがフロントエンド データ レンダリングに使用できます。プロキシ プロセス全体はブラウザに対して透過的です。
7. インターフェイス設定ファイル自体は構造化された記述ドキュメントであり、リバー ツール コレクションを使用してドキュメントを自動生成できます。また、関連する自動インターフェイス テストにも使用でき、開発プロセス全体が閉ループを形成します。
これは簡単な例です:
【例1】
最初のステップは、プロジェクト ディレクトリにインターフェイス構成ファイルinterface.jsonを作成し、そこにメインの検索インターフェイス json 定義を追加することです
{
"title": "パッドタオバオプロジェクトデータインターフェースコレクション定義",
"バージョン": "1.0.0",
"エンジン": "mockjs",
"ルールベース": "./interfaceRules/",
"ステータス": "オンライン",
"インターフェース": [ {
"name": "メイン検索インターフェイス",
"id": "Search.getItems",
「URL」: {
"オンライン": "http://s.m.taobao.com/client/search.do"
}
}]
}
ステップ 2: コードでモデルを作成して使用する
//モジュールを導入します
var ModelProxy = require( 'modelproxy' );
// グローバル初期化により、インターフェイス構成ファイルが導入されます (注: 初期化作業は 1 回だけ発生します)
ModelProxy.init( './interface.json' );
//モデルを作成します。その他の作成モードについては、次の記事を参照してください。
var searchModel = new ModelProxy( {
SearchItems: 'Search.getItems' // カスタム メソッド名: 設定ファイルで定義されたインターフェイス ID
} );
// モデルを使用する場合、メソッドを呼び出すために必要なパラメーターは、実際のインターフェイスで必要なパラメーターであることに注意してください。
searchModel.searchItems( { q: 'iphone6' } )
// !上記で searchItems を非同期的に呼び出して取得したデータを取得するには、コールバック関数を指定するために、done メソッドを呼び出す必要があることに注意してください!
.done( function( data ) {
console.log( データ );
} )
.error( function( err ) {
console.log(err);
} );
ModelProxy の豊富な機能は、必要なビジネス モデルを作成するためにさまざまな形式のプロファイルをサポートしていることです。
インターフェイス ID を使用して作成> 生成されたオブジェクトは、ID の最後の「.」の後の単語をメソッド名として受け取ります
ModelProxy.create( 'Search.getItem' );
Key-Value JSON オブジェクトを使用> カスタム メソッド名: インターフェイス ID
ModelProxy.create( {
GetName: 'Session.getUserName',
GetMyCarts: 'Cart.getCarts'
} );
配列形式を使用> 最後の . の後の単語をメソッド名として取得します
次の例で生成されるメソッド呼び出し名は次のとおりです: Cart_getItem、getItem、suggest、getName
ModelProxy.create( [ 'Cart.getItem', 'Search.getItem', 'Search.suggest', 'Session.User.getName' ] );
プレフィックス形式> プレフィックスを満たすすべてのインターフェイス ID がオブジェクトに導入され、後半がメソッド名として使用されます
ModelProxy.create( '検索.*' );
同時に、これらのモデルを使用すると、マージリクエストや依存関係リクエストを簡単に実装し、関連するテンプレートのレンダリングを行うことができます
【例2】マージリクエスト
var model = new ModelProxy( 'Search.*' );
// マージリクエスト (done を除き、以下で呼び出されるモデルメソッドはすべてインターフェイス ID の設定時に指定されます)
model.suggest( { q: '女性' } )
.list( { キーワード: '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;
// 2 番目のデータリクエストは、初めて取得した ID 番号に依存します
This.getMyOrderList( { id: uid } )
.done( function(data) {
console.log(データ);
} );
} );
また、ModelProxyはNode側だけでなくブラウザ側でも利用できます。公式パッケージで提供されているmodelproxy-client.jsをページに導入するだけです。
【例4】ブラウザ側でModelProxy
<スクリプトタイプ="text/javascript">
KISSY.use( "モデルプロキシ", function( S, ModelProxy ) {
// !2 番目のステップで設定したインターセプト パスと一致する基本パスを設定します!
// そして、グローバル構成は 1 回だけです。
ModelProxy.configBase( '/model/' );
// モデルを作成します
var searchModel = ModelProxy.create( 'Search.*' );
検索モデル
.list( { q: 'ihpone6' } )
.list( { q: 'ジャケット' } )
.suggest( { q: 'i' } )
.getNav( { q: 'スケートボード' } )
.done( function( data1, data2, data3, data4) {
console.log( {
"list_ihpone6": data1,
"list_Jackets": data2,
「suggest_i」: data3,
"getNav_skateboard": data4
);
} );
} );
同時に、ModelProxy を Midway のもう 1 つのコア コンポーネントである Midway-XTPL と併用して、ブラウザー側とサーバー側でデータ、テンプレート、および関連するレンダリング プロセスの完全な共有を実現できます。 ModelProxy に関する詳細なチュートリアルとドキュメントについては、https://github.com/purejs/modelproxy
にアクセスしてください。概要
ModelProxy は構成済みの軽量フレームワークとして存在し、使いやすいインターフェイス モデルのアセンブリと使用法を提供すると同時に、フロントエンドとバックエンドの開発モデルの分離におけるインターフェイスの使用仕様の問題をうまく解決します。プロジェクト開発プロセス全体で、インターフェイスの定義と説明は 1 回だけで済み、フロントエンド開発者はそれを参照できると同時に、River ツールを使用してドキュメントが自動的に生成され、バックエンド開発者との契約が形成されます。これにより、ソフトウェア エンジニアリング開発プロセス全体が大幅に最適化されます。
【注】Riverとは、アリババグループが開発したフロントエンドおよびバックエンドの統一インターフェース仕様および関連ツール集の総称です