1

問題 - (バックストーリー)

最近、私はいくつかのインタビューを受けましたが、4 つのインタビューすべてで「X は MVC アプリのどこにあるのですか?」という質問が絶えず出てきました。

問題は、面接する会社が毎回違うことでした。2 つは主に ASP.NET MVC / Microsoft ショップで、他の 2 つは Ext.js、Ember.js、Angular.js、またはその他の JavaScript MVC フレームワークを使用していました。

私の答え -

ビジネスロジックはどこにありますか?

ASP.NET MVC

サーバー上の別のレイヤー

JavaScript MVC

理論的には、コントローラ上またはその周辺... しかし、安全ではありません...

検証はどこにありますか?

ASP.NET MVC

モデルでは、ビューは単に問題を警告するためにそれを使用し、コントローラーはコミットを試みる前にモデルの状態を検証します。

JavaScript MVC

ええと、モデルでは...ビューではちょっとですが、コントローラーはそれを提供します...

何が正しいですか？

私の質問は、ASP.NET MVC と比較した場合に、次の基本的な関数を JavaScript MVC で適用する必要がある場合に、意見ではなく事実によってサポートされる違いは何ですか?

カテゴリー -

ビジネスロジックはどこにありますか?

検証をどこに適用する必要がありますか?

検証はどこで確認する必要がありますか?

この質問に他にどのような質問を貸す必要がありますか?

4

2 に答える 2

0

ビジネス ロジックのクライアント側は、エンド ユーザーにとって便利なだけです (場合によってはパフォーマンスも向上します)。

サーバーにアクセスするまで、ビジネス ロジックの検証を適用する必要はありません。

サーブを打った後は、ビジネス ロジックを確認/適用する必要があります。これは、制御できない環境を真に信頼することはできないためです。

少しの間、私たちが Gmail であると想像してみてください。いくつかのシナリオを実行できます。

ビジネスロジックが、電子メールを送信できることがわかっている人のリストをポップアップ表示するなど、いかなる種類の検証とも関係がない場合、それはクライアント側に属します。

ビジネス ロジックが、誰かが何らかの悪意のある HTML を電子メールに忍び込ませていないことを確認している場合、その検証はサーバー側で行う必要があります。

悪意のある私は、HTML に悪意のあるコードを含む電子メールを作成したふりをして、gmail への ajax 呼び出しを模倣することができます。しかし Smart Google は振り返り、通話の内容をチェックして、私が無効な情報を偽装していないことを確認します。

于 2013-08-13T16:02:40.253 に答える