私は MVC を 2 年間勉強してきましたが、いくつかの概念はまだ曖昧です。ここで答えを見つけることができれば幸いです。
コントローラーはデータ処理に責任がなく、Web ページのフロントエンドから返されるデータ型が何であれ、データ型はすべてサービスに直接転送され、すべてサービスによって処理される、と言っている人を見たことがあります。その後、サービスがそれを処理しますが、オブジェクトがコントローラーでカプセル化されている場合、サービス メソッドで複数回呼び出される場合があるという別の声もあります。
もう 1 つの質問は、コントローラーとサービスの間の対話に関するものです。
フロントエンドでの顧客との良好な対話を確保するために、ユーザー名がすでに存在する、ユーザー名とパスワードが一致しないなど、コントローラーを通じていくつかのエラープロンプトをフロントエンドに返すことがよくあります。ただし、ビジネス ロジックはサービス層で処理されるため、login(String username, String password) メソッドの戻り値が boolean に設定されている場合、複数のエラーを返すことはできません。返された場合は、いくつかの基本的な設定を行う必要があります。
私自身の「派手なアイデア」は、サービスでいくつかのカスタム RuntimeException をスローし、コントローラーで TryCatch を使用してさまざまなエラーを処理するというものですが、この例外をスローする方法は不適切だと思います。私は最近混乱しており、次のプロジェクトに取り組み始めようとしています。私の混乱を解消するのを手伝っていただければ幸いです。
ありがとうございます。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
私たちのプロジェクトは 3 つのレベルに分かれています:
プレゼンテーション層: Spring MVC、HTTPリクエストの受信、結果の表示(返し)、および簡単な検証を担当します
アプリ層:インポート、エクスポート、複雑な検証などのアプリケーション層機能を提供します
ドメイン層: 一部のサービスなどのビジネスロジックを処理します
呼び出しシーケンスは 1 つです: コントローラー -> アプリ -> ドメイン
そして、認識関係は次のとおりです: コントローラー -> アプリ -> ドメイン、つまり、下位層は上位層を認識しません
まず最初の質問に答えさせてください:
あなたが言及した最初の質問は、HTTP リクエストによって受信されるパラメーターはオブジェクトではなく、一連の基本的なタイプであるが、サービスによって受信されるパラメーターはオブジェクトであることを意味すると理解できますか。正しいアプローチは、「生の」パラメータをコントローラの Object オブジェクトに変換してから、サービスを呼び出すことです。
なぜこれが正しいのでしょうか?サービスはビジネス ロジックを含むドメイン層に属しているため、サービスが受け入れるパラメータは、さまざまなシナリオで再利用できるように、Web 層からのパラメータを考慮する必要はありません。
たとえば、サービスはさまざまなプレゼンテーション層環境で再利用できる必要があります。
Web プログラムでは、ユーザーによって渡されたパラメータは POST/GET の形式で与えられます
Webサービスプログラムでは、ユーザーが渡すパラメータはjsonまたはSOAPです
Swing プログラムでは、ユーザーによって渡されるパラメータは文字列です
Service を特定のプレゼンテーション層環境にバインドすると、そのメソッド パラメータは確実に不安定になり、再利用できなくなります。
同様に、Service の戻り値は特定のシナリオにバインドされるべきではありません。
Spring MVC レベルでは、コントローラーはパラメーターをオブジェクトや関連ドキュメントに簡単に変換できます
2番目の質問:
この質問は 3 つの部分に分けることができます:
1) パラメータの長さ制限や空でない判定などの簡単な検証はどこで行うのでしょうか？
Spring MVC自体が提供する仕組みや関連ドキュメント、関連ドキュメントを利用して簡易検証を行っています
2) 注文時にユーザーのアカウントが無効になっているかどうかの判断など、サービス自体のビジネス ロジックと並行して検証はどこで行われますか?
これらのロジック チェックはアプリ層で行うことが多く、コントローラーはアプリを呼び出し、アプリは 2 つの異なるサービスを呼び出してビジネスを統合します
3) サービス自体に関わるビジネスロジックの検証方法
ログインの例を挙げましたが、例外を利用して呼び出し元(Controller)に処理結果を通知するのは問題ありません。この目標を達成するために Service の戻り値を強化することもできますが、Service の戻り値の設計はプレゼンテーション層環境にバインドできないことに注意してください。そうしないと再利用できません。これが @YaTou が apache-hiro について言及した理由です。認証失敗の処理には例外メカニズムが使用されます。これだけが一般的であるためです。再利用できると思います
「コントローラーでオブジェクトをカプセル化するので、サービスメソッドで複数回カプセル化する必要はありません」ということについては、それぞれにどのようなパラメーターを与えるのかがよくわかりません。必要なパラメーターをカプセル化する必要があるかどうかを確認します。ターゲットになったら、自分で評価できます。Controller不负责处理数据是正确的, 因为在spring-mvc中Controller是不能复用的, 但是如果你把业务逻辑抽象成Service, 那么这个Service
は、認証失敗のさまざまな状況を処理するために例外を使用するということです。Service需要什么参数,Controllerあなたが言ったこと最初の質問に対する標準的な答えはありません。特定の状況を分析し、ロジックの階層を明確にして保守しやすくすることをお勧めします。
2 番目の質問に関しては、ここで指定したインタラクションは、通常、フィルター、AOP、プロキシ、リフレクションなどを使用して、これらの集中制御コードでも例外がスローされます。それはいいのですが、コントローラーに直接ハードコーディングするのは面倒だと思います。サービス層は、Dao 層のメソッドを呼び出して、複数のテーブルが関与する複雑なビジネス ロジック処理を実装することを目的としています (もちろん、フレームワークがすべてを実行しています)。そのため、サービス層は通常、この層には配置されません。例外をスローします (パラメーターの検証はコントローラーとその前のレイヤーで行われるため、ビジネス関連の例外は発生せず、Dao はデータベースに関連する基礎的な例外をブロックします)。
もちろん、これは個人的な意見であり、決まった公式はありません。先ほども言いましたが、レイヤーがクリアでメンテナンスが簡単であれば良いです。
1. コントローラーはデフォルトではシングルトンですが、 @Scope(value = "prototype") に置き換えることができます
2. ログインは int を返すことができ、自分で列挙を追加できます
3. ロジックはサービス層で処理することが規定されており、コードの冗長性は少なく最適化した方が良いです。
開発において重要なことは、何をしなければならないかではなく、最適化と修正、冗長性の削減です。 。 。1. コントローラーは可能な限りビジネス ロジックを設計せず、対話のみを行う必要があります
2. サービスは再利用可能なビジネス ロジックです
3. コントローラーはサービスの上位の呼び出し元です
4. あなたの場合、サービスで固定値を返すことができます。値を返し、コントローラー層で判断し、対応する必要な例外をスローします。
もちろん、これは単なる現在のアプローチです。ぜひ共有してください。 。 。
私の記事を読むことができます
AOP、MVC - CodeIgniter /a/11... に関する春の学習と考察...
ロジックをサービスに配置することをお勧めします。現在、分散マイクロサービス アーキテクチャに取り組んでいます。これを分割する際に、基本的にいくつかのインターフェイスを再作成しました。使用する必要のあるアプリがコントローラー上にあると共有できません。
カプセル化されたオブジェクトがコントローラーにあるかサービスにあるかは、特定の状況によって異なりますが、単純なパラメーターであれば、サービスに配置されている場合は、カプセル化しても問題ないと個人的には思います。非常に冗長に見え、サービスの汎用性の低下につながります。2 番目の質問では、コントローラー上で判断を行って例外をスローするために列挙コードや別のステータス コードを使用することは許可されていません。このプロジェクトは、サービス エラー メッセージとエラー コードをビュー層に直接返し、クライアントがステータス コードとエラー コードに基づいて処理できるようにする、ビジネスライクな例外処理メカニズムをターゲットとしています。エラーメッセージ