システムを行うには、フロントエンドのページは、基本的にJavaScriptのリッチエンドページの使用は、フレームワークの主なアプリケーションは、jquery、jquery uiは、ノックアウトjsは、デュランダル、加えて、独自のパッケージUIコンポーネントのいくつかありますが、ODataに使用される主な技術のバックエンドは、MVCは、SQLにLinqは、独自の権利管理コンポーネントを書いて、使用するデータベースはSQL Server 2005です。
以下、ユーザー・インターフェースから順に、各モジュールの機能とその分割の目的を紹介します。
I. フロントエンドのdataProviderについて
簡単に言えば、それはインターフェイスの呼び出しにデータアクセス層であり、多くの人々がそのような疑問を持って、ここにデータアクセス層を追加し、冗長ではありませんか？フロントエンドを行う限り、次のような問題が発生します：
1、製品やプロジェクト、フロントエンドとバックエンドを同時に実施し、この時点で、バックエンドのインターフェイスがない、あるいは言うことができる、インターフェイスの定義もありません。フロントエンドの開発者として、どのように仕事を進めていますか？
2、バックエンドのインターフェイスがハングアップするため、フロントエンドの開発者として、あなたは今までに遭遇した、その結果、仕事は状況を行うには続行できませんか？
3は、フロントエンドの開発者として、多くの場合、必然的とドッキングのためのサードパーティのインターフェイスは、あなたが今まで遭遇したことがあり、あなたは、ドッキングの担当者を行う突然、プロジェクトがタイトであるため、N個のパラメータを渡す必要性の束だけを残して、離れて描画されたパスの後、"オブジェクトが空です "例外のうち？あなたは、単にパラメータが間違って渡された場所を知りません。これらのインターフェースに直面して、あなたは罵る以外の助けを得ることはできません。
4、フロントエンドの開発者として、あなたは今まで、バックエンドの開発チームに、インターフェイスをしたい、彼らは数日を議論する必要があり、その後、あなたを与えるために、数日を費やすが、使用することはできませんし、それをデバッグするために数日を費やす必要がある、試してみましたか？
もしあなたが私のように、以前このような問題を抱えていたなら、このdataProviderの必要性を疑うことはないでしょう。以下にdataProviderの例を示します：
var dataProvider = (function () {
var fakeProvider = {
countries: new Countries()
};
var realProvider = {
countries: new JData.WebDataSource()
};
//以下のインターフェースは、状況に応じて2つ選択できる。
return fakeProvider; //这个是假的 dataProvider，从本地读
return realProvider; //这个是真正 dataProvider，从接口读
})();
fakeProviderはシミュレートされたデータを提供し、realProviderはインターフェイスから読み込まれたデータを提供します。インターフェイスがないとき、あるいはインターフェイスがハングアップしているときは、まずfakeProviderからデータを読み込みます。インターフェースの準備ができたら、realProviderに切り替えます。
II.ユーザーインターフェース入力の検証について
1.データの検証。ユーザーがインターフェイスでデータを入力し、dataProviderのデータ処理でインターフェイスを呼び出しますが、サーバーに提出され、あなたが最初にデータを検証する必要があります。どのようにデータを検証するには、dataProviderは、まずサーバーからエンティティ情報の説明を取得し、これらの記述が含まれますが、これらに限定されない：主キーと外部キー、属性検証情報、もちろん、このエンティティ情報を再利用するためにキャッシュすることができます。dataProviderは次に、この記述に対してデータを検証します。
2.エラーメッセージの表示
プロパティがバリデートされない場合、情報をバリデートするモジュールはページ上の対応する入力コントロールを検索しますが、どのように検索するのでしょうか？例えば、Name of Contryが空の場合、それは許可されません。その場合、idがCoutryである要素を探し、Coutry要素の下にあるidまたはnameがNameであるコントロールを探し、見つからない場合は直接ポップアップウィンドウでエラーメッセージを表示します。例えば
<form id="Country">
<input name="Name"/>
</form>
III.ODataのバックエンドでの使用について
1、バックエンドの開発者として、あなたは今までこのフロントエンドの開発者に遭遇したことがありますか？明日は、フィールドを追加してみましょう。突然言った翌日、フィールドを追加するには、最初の2日間は必要ありませんが、あなたは "ファック "衝動を叫びたいの一種を持っていないのでしょうか？
2、バックエンドの開発者として、あなたは今までこのようなフロントエンドの開発者に遭遇した、今日はインターフェイスがGetUserByNameメソッドを追加するには十分ではないことを言った、明日もGetUserByEmailメソッドを追加するには？その後、時間の期間の後、あなたは、インターフェイスがますます多く、モジュールのメンテナンスがますます多くの癰であることがわかり、これらのインターフェイスは、あなただけを追加する勇気がない、削除する勇気がありません。なぜなら、あなたは、単に使用しない、あなたはフロントエンドに依頼するために実行して、彼は答えることができない、これらを知りません。だから、いくつかのインターフェイスは、それが使用されていない場合でも、唯一のライフサイクルの終わりまで、システムで永遠にすることができます。
もしあなたが私と同じようなトラブルを経験しているのであれば、ODataを使用することで、フロントエンド開発者に好きなだけクエリを実行するすべての権限を与え、そのままにしておくのも良い選択肢かもしれません。
IV.バックエンドでのMVCの使用について
MVCを使用するシステムは、フロントエンドから提出されたデータを処理するために使用され、それを使用して、主に開発者がMVCに精通しており、その後、MVCは、ビジネス層のコードを呼び出すと、同時に、対処する必要があります。
1.提出データの検証
2、システム例外の処理。例外を再パッケージ化し、より簡単に処理できるようにクライアントに戻すことを含みます。例外に関する情報の記録
V. データ・アクセス層
データアクセスレイヤーについては、実際にはシステム内のORMのラッパーであり、ORMにベニヤを巻いているようなものです。その目的は
1.データの傍受例えば、ある特定の役割のためだけに開発されたデータがあります。データアクセスレイヤーは、フィルタリング条件に基づいてSQLを再生成し、クエリ条件と組み合わせる必要があります。
2、データの偽の削除の処理。多くのシステムを見ていると、業務レイヤを削除して実行するように置かれていますが、実は、これは、削除を懸念するビジネスの観点から、適切ではありません、削除の実装では、私の目からこのデータは、その上に消えました。本当の削除や偽の削除については、それは私には何の関係もありません。データアクセスレイヤは、この作業を行うには、それが真の削除と偽の削除の間の切り替えのデータにすることができます限り、設定として、あなたは偽の削除に真の削除することができますので、ビジネス開発者は、データの真または偽の削除を気にする必要はありません。
3、データの追跡とバックアップ。データを更新するたびに、更新した時間や更新した内容を記録する必要があります。データを削除した場合、それを復元できるようにするためです。データアクセスレイヤーは、ORMをラップすることで、すべての更新と削除を記録し、ログに記録することができます。もちろん、これらの要件はデータによって提供される機能を使って実現することも可能であり、この議論の範囲を超えています。
