簡単なユーザー挿入操作について考えてみましょう。この仕事をするための私のSpring関連のクラスはUserController、、、、UserServiceです。UserServiceImplUserDAOUserDAOImpl
コントローラー側で呼び出しuserService.insert(new User())、userService.insert()メソッドで呼び出しますuserDAO.insert(user)。このパターンでメソッドの重複があると思います。
メソッドの重複を避ける方法はありますか? 私のコーディングが間違っている可能性があります。私はあなたの返事、経験を待っています...
少し早いですがお礼を...
重複ではないと思います。非常に悪い名前を使用したと思います（重複のように見えます）。
サービス メソッドはユーザーを「作成」し、DAO メソッドはそれを「挿入」または「保存」します。
これで、「作成」と「挿入」が異なるスコープと異なる抽象化レベルを持つ 2 つの異なるアクションであることがわかります。したがって、重複はありません。
The structure you describe is, apart the mentionend name confusion, a good starting point. Depending on the complexity you can just leave the interface classes out and you end up with three classes. If your application is small (to medium) i consider this a legit approach even if it is not best practice. Introducing an interface once you discover there are alot of dependencies and you need some kind of api package for a part of you app is easy to introduce with spring as long its not the whole app.
One other thing you have to keep in mind is that you do not need to multiply this complete chain of classes for each usecase. A generalized SimpleCrudDao and SimpleEntityService is perfectly fine. Then once this SimpleEntityService is not enough you can start creating specifc ones like a UserService that has createUserAndTransferEntitiesAndUpdateWhatsoever methods.
あなたが概説したものはうまく見え、ビジネス サービス パターンの多くの実装に適合します。混乱を引き起こしている可能性があるのは、一般に、メソッド/関数を記述する言語が各レイヤー間で異なることです。たとえば、「挿入」はよりデータの永続的な用語ですが、ビジネス/サービス層はユーザーを「作成」したいと考えています。違いの理由は、通常、概念に違いがあるためです。サービス層でのユーザーの「作成」は、1 つの「オブジェクト」である「ユーザー」にすぎませんが、DAO 層では、実際にはいくつかの手順が必要です。1. 「ユーザー」を作成します。2. 別のテーブルに「アドレス」を作成します。3. それらを任意のセキュリティ グループに追加します。
したがって、あなたの場合、実際には1対1である可能性があり、多くの場合、ビジネスレイヤー1は多くのDAO相互作用に相当します。