Angularjs では、すべてのビジネス ロジックが Javascript に埋め込まれたオブジェクトを格納するためだけに、安らかなサーバー API を使用することができます。ほとんどの例は、その方向を指しているようです。
これは、保守性とセキュリティの両方の点で悪い習慣ではありませんか?
3310 次
1 に答える
11
この質問は少し漠然としていますが、大まかな回答をしようと思います。ロジックをクライアント側に移行することは悪い習慣だとは思いません。
保守性
ヘブンズノー！私はバックエンドでキャリアをスタートさせましたが、コードが前面にあるか背面にあるかは保守性に影響しないと確信を持って言えます。コードはコードです。クライアント上の再利用可能なサービス コンポーネントに配置する場合でも、サーバー上の再利用可能なライブラリに配置する場合でも、変更管理は非常に似ています。重要な追加の注意事項については、セキュリティ セクションを参照してください。
ビジネスの論理
正直なところ、なぜ開発者がビジネス ロジックに関してそれほど口を閉ざすのか、私にはまったく理解できませんでした。彼らの心の中では、誰かが自分のコードをリバース エンジニアリングするだけで、想像もしていなかった魔法のような現実を発見するかのようです。彼らは、開発者の天才の証人となるでしょう! - そして今、市場侵略行為を行うのに十分な武装をしている.
これはばかげています。彼らはあなたのサービスを見ることができます。彼らはあなたのユーザーインターフェースを見ることができます。彼らは目標を知っています。彼らがあなたを複製したいのなら、彼らはすでにできています。ビジネス ロジックが製品の鍵となることは非常にまれです。99%のケースでは問題ありません。
そして、ビジネスの中心にある非常に複雑なアルゴリズムは、いずれにしてもクライアントに行き着くわけではありませんよね? map/reduce 操作とセマンティック グラフを使用して、分散ファイル ストアを大幅に処理します...
安全
これは常に重要な考慮事項ですが、鍵は REST API にあります。REST API は、改ざんできない公式のゲートウェイです。userモデルにフィールドが必要な場合、first_nameそのフィールドが存在することを確認するのは REST API の仕事です。クライアント側にもチェックを導入する可能性がありますが、これらはほとんどの場合、ユーザー エクスペリエンスを念頭に置いて作成されています。同期的で即時のフィードバックは、非同期で遅延したフィードバックよりも優れています。
厳密に定義されたセキュリティに関連するものはすべてサーバー上にあります。認証と承認は明らかにサーバー上にあります。それらはクライアント上にはありません。そのため、シングルページ アプリケーション パラダイムを選択することで、脆弱性が生じることはありません。Twitter、Google 製品、または Facebook について考えてみてください。それらはすべて、同じ目標を達成するために Web インターフェースの代わりに使用できるオープン API を備えています。API は重要なルールを適用し、適切なセキュリティを確保しますが、ユーザー エクスペリエンスはクライアントに任せます。
明らかに、これは、基本的な検証など、一部のロジックがクライアントとサーバーで重複していることを意味します。もちろん。しかし、私たちはユーザーエクスペリエンスのためにそれを行います. これにより、変更管理プロセスが少し複雑になりますが、ユーザー エクスペリエンスの向上はそれをはるかに上回ります。
于 2013-04-06T17:52:44.177 に答える