Javascriptでのドメインモデルの実践（フレームワークを使用）

これは私がしばらく行ったり来たりして検索して何も見つかりませんでした質問です：バックボーンのようなフレームワークを使用しているときに、Webアプリケーション用のJavascriptでドメインモデルを複製することに関して受け入れられているプラ​​クティスは何ですか？またはノックアウト？

サーバー側に一連のドメインモデルを持つ重要なサイズのWebアプリケーションがある場合、これらのモデルをWebアプリケーションに複製する必要がありますか（下部の例を参照）。または、動的な性質を使用してこれらのモデルをサーバーからロードする必要がありますか？

私の考えでは、モデルを複製するための議論は、フィールドの検証を容易にし、存在すると予想されるフィールドが実際に存在することを保証することなどです。私のアプローチは、クライアント側のコードをほとんど別のアプリケーションのように扱い、些細なことをすることですそれ自体、データと複雑な操作（クライアント側にはないデータを必要とする）をサーバーに依存しています。クライアント側のコードをこのように扱うことは、ORMのエンティティとUIレイヤーのビューで使用されるモデルを分離することに似ていると思います。それらは同じフィールドを持ち、同じドメインの概念に関連しているかもしれませんが、それらは別個です事。

一方、サーバー側でこれらのモデルを複製することは、DRYの明らかな違反であり、クライアント側とサーバー側で異なる結果をもたらす可能性があるように思えます（一方が更新されても、もう一方は更新されません） ）。このDRYの違反を回避するには、JavaScriptのダイナミズムを使用して、必要なときにサーバーからフィールド名とデータを取得します。

それで、これらの状況で自分自身をいつ繰り返すか（そうでない場合）について、認められたガイドラインはありますか？または、これはプロジェクトと開発者に基づいた純粋に主観的なものですか？

例

サーバー側モデル

class M 
{
    int A
    DateTime B
    int C
    int D = (A*C)
    double SomeComplexCalculation = ServiceLayer.Call();
}

クライアント側モデル

function M(){
    this.A = ko.observable();
    this.B = ko.observable();
    this.C = ko.observable();
    this.D = function() { return A() * C(); }
    this.SomeComplexCalculation = ko.observalbe();
    return this;
}l
M.GetComplexValue = function(){
    this.SomeComplexCalculation(Ajax.CallBackToServer());
};

この質問はこれと非常に似ていると思いますが、これはサーバーからWebアプリケーションをほとんど完全に切り離すことに関するものだと思います。この質問は、複雑な計算の場合にのみこれを行うことに関するものです。

良いデザインパターンとBreezeのようなフレームワークが役立つと思います。クライアントでドメインモデルを繰り返さないでください。ドメインモデルはサーバーに残したまま、Breezeを使用してモデルをクライアントにプルしてください。

以下は、リポジトリと作業単位パターンでbreezejsを使用する良い例です。

https://github.com/yagopv/DurandalAuth

ドメインモデルはサーバー上に保持され、微風はメタデータを読み取り、サーバーからローカルにエンティティを作成します。これはあなたの問題の素晴らしい解決策だと思います。JSを介してローカルエンティティフレームワークタイプのアクセスをローカルで取得し、モデルをサーバーに保持できます。質問で取り上げた問題のバランスが取れていると思います。

あなたの実際の質問は少し一般的であるため答えることは困難ですが、フォーム検証の例はもう少し具体的であるため、私はそれを使い続けます。

あなたが言ったように、あなたは常にできるだけ乾燥しているべきです。これは、開発者として心に留めておくことは良いことです。ただし、類似しているものを区別する必要があり、類似していることを繰り返すことは避けますが、目的が異なります。

フォーム検証の例を見てみましょう。サーバー上の検証コードの目的は、たとえばデータベースに入力するためのユーザーの電子メールアドレスがあることを確認することです。そのため、登録プロセスではユーザーのメールアドレスが必要なので、登録プロセス中に確認します。

しかし、クライアント側のJavaScriptコードの目的は何ですか？はい、それは電子メール入力フィールドで検証を行いますが、全体のアイデアは次のとおりです。ユーザーが既に電子メールアドレスを入力したかどうかを確認し、それ以外の場合はサーバーに送信する前にアラートを表示します。したがって、クライアント側のフォーム検証の目的は、サーバーへの不要なデータの送信を停止し、数秒後にエラーメッセージを表示してアプリケーションフォームを再送信することです。どうして？ユーザーにとって煩わしいからです。サーバーでのみフォーム検証関数を保持する必要があると思いますか？いいえ、目的が異なるためです。

クライアント側でのフォーム検証の目的は、ユーザーを信頼できないことではありません。チェックしてみましょう。しかし、検証エラーメッセージを取得するためだけにサーバーとの通信を回避しようとしているUXです。ただし、サーバー側でのフォーム検証の目的は、ユーザーを信頼できないこと、ユーザーが何を要求しているかを確認すること、そしてユーザーがAPIリクエストである可能性があることです。クライアント側で。

このように見ると、フォーム検証の例は、WETと感じさせることなく、まったく問題ありません。

実際の質問については、サーバー上のすべてまたはクライアント上のすべてを保持しようとしないでください。それは本当に仕事に依存します。ユーザーの大きな大きなCSVファイルを解析する必要があり、Webサイトに100人のユーザーしかいない場合、モバイルユーザーがいることがわかっていれば、サーバーでそのファイルを解析して適切な簡単なファイルを出力できます。からクライアントへのダイジェストマークアップ。ただし、何百万人ものユーザーがいる場合は、自分のマシンでファイルを解析しようとします。Webブラウザーを使用して、サーバーの焼損を回避するための処理能力を使用します。そのため、解析機能は、サーバーまたはクライアントのいずれかである可能性があります。

ただし、物をどこに保管するかわからない場合は、サーバーに保管して結果をユーザーに提供します。サーバーとクライアントの両方でコードが重複しないようにしてください。