データベースサービス関数を呼び出すアプリケーションサービス層。悪いアーキテクチャ？

シナリオ：

• スタック：Java、Spring、Hibernate。
• モデル：クライアントサーバーアプリケーション。
• パターン：Model-View-Controller（MVC）。

サービス層クラスには3つの動作があります。

1. 一部のサービスには、メソッド内にビジネスルールがあり、永続性をアプリケーションに委任します。お気に入り：

   EntityManager.save（entity）;

2. 一部のサービスは、単純にデータベース関数（パラメーターを渡す）を呼び出します。

   CallableStatement cls = con.prepareCall（ "{call databaseFunction（args）}"）;

3. 一部のサービスには、両方の動作を持つメソッドがあります。

私の質問：

1. アプリケーションサービスに直接データベース機能を呼び出しても問題はありませんか？これは悪い習慣ではありませんか？このようなプロジェクトに適用できるアーキテクチャモデルは何でしょうか？
2. 同じサービスで動作が混在することに問題はありますか？トランザクションや一貫性など？
3. メンテナンスの場合、このカプセル化により、開発者はデータベースの機能も変更する必要があることがわかりにくくなりますか？これを回避するには？
4. このシナリオは世界中の他のアプリケーションで発生しますか、それとも単なるアーキテクチャ上のエラーですか？

アプリケーションサービスに直接データベース機能を呼び出しても問題はありませんか？これは悪い習慣ではありませんか？

あると思います。アプリケーションサービスのデータベース内部に関する知識を配置します。何らかの方法でデータベースを変更する（ストレージエンジンを変更する、フィールドの名前を変更する、またはインデックスを作成する）には、アプリケーションサービスを変更する必要があり、これはSRPに違反します。

このようなプロジェクトに適用できるアーキテクチャモデルは何でしょうか？

以下のコメントを参照してください。

同じサービスで動作が混在することに問題はありますか？トランザクションや一貫性など？

技術的な問題はないと思いますが、論理的な問題があります。アプリケーションで2つのアプローチを混合するだけで、漠然としていて、構造化されておらず、変更への適応が困難になります。SRP違反に関する上記のコメントも参照してください。

メンテナンスの場合、このカプセル化により、開発者はデータベースの機能も変更する必要があることがわかりにくくなりますか？

もちろんです。

これを回避するには？

データベースと直接連動するメソッドと関数を別の抽象化レベルに配置します（DAOレイヤーか単純なリポジトリパターンかに関係なく、アプリケーションの複雑さに依存します）。

このシナリオは世界中の他のアプリケーションで発生しますか、それとも単なるアーキテクチャ上のエラーですか？

私たちの世界ではすべてが起こると思います;）

あなたの言ったところによると、サービスレイヤーがあるので、適切と思われるアーキテクチャパターンはレイヤードアーキテクチャです。さらに参照

ええ、通常、データアクセスレイヤー以外で直接データベースコールを行うのは悪い習慣です。そのため、ビジネスレイヤーはデータベースの抽象化にのみアクセスします。

ミキシング動作に関しては、DAOパターンまたはリポジトリパターンとしていくつかのデザインパターンを使用すると、その責任を委任してコードを改善するのに役立ちます。

デザインパターンとORMを使用する利点のいくつかは、コードの可読性、責任のカプセル化であるため、データベースアクセスが変更されても、ビジネスレイヤーはあまり変更されません。