私の主要な開発フレームワークは、Javaの春のフレームワークです。私は、サービス層、コントローラ層、DAO層、リポジトリ層などを書く必要があります。数千トンの層があります。コンポーネントベースの開発アプローチはレイヤリングよりも生産的になるだろうと私は思います。 SpringはすべてのJava Beanをコンポーネントとして呼び出します。しかし、コンポーネントとレイヤの間には大きな違いがあるはずです。一般に、コンポーネントがアクティブな場合、レイヤーは受動的です。コンポーネントはイベントを発生させ、ライフサイクルコールバックメソッドを呼び出し、タスクを積極的に処理します。一方、レイヤーは抽象化のみを提供します。では、レイヤとコンポーネントの基本的な違いは何ですか？レイヤとコンポーネントの違いは何ですか？
レイヤーとコンポーネントの概念は異なりますが、レイヤーとコンポーネントは互いに置き換えられません。レイヤーは抽象です。データベースのやりとりやHTTPエンドポイントハンドラからビジネスロジックを抽象化します。レイヤーはコンポーネントで構成されます。あるレイヤーに複数のコンポーネントがある場合があります。
具体的な例を続けてみましょう。あなたのシステムには、UserとGroupのエンティティがあります。両方に必要なエンドポイント・ハンドラーがあり、名前はUserControllerおよびGroupControllerです。これらはコンポーネントであり、一緒にエンドポイントハンドラレイヤとして形成されます。ビジネスロジックの場合は、UserServiceとGroupServiceになります。これらはコンポーネントであり、サービスレイヤーとして形成されます。 UserRepositoryとGroupRepositoryコンポーネントのデータベースレイヤーでも同じです。
フルスタックコンポーネントを使用する場合は、すべてのレイヤがハンドラに凝縮されます。つまり、UserControllerは、要求を取得し、ビジネスルールを適用し、dbにアクセスするまでのすべてを実装します。この構造はテストするのが難しく、維持が難しい。いくつかの点の後、コードは非常に扱いにくく扱いにくいものになります。ユニットテストはありません。すべてをテストする統合テストだけがあります。データベースのアクセス方法を変更するオプションはありません。誰かがテスト目的でメモリ内リポジトリの実装を使用したいかもしれませんが、この手法では許可しません。全体として、レイヤードアーキテクチャは最初は複雑に見えるかもしれませんが、長期的には便利です。
P.S .:コンポーネントでこれ以外のものを意味する場合は、コメントを残してから、引き続き議論を進めることができます。
レイヤーとコンポーネント化は、2つの設計アプローチに続いて、アーキテクチャ上の問題があります。
建築/設計は、再利用性、拡張性 、機能のモジュール化&保守の種類を達成する必要性を施行する場合は、 レイヤーはあなたを助けるでしょう。
アプリケーションが複雑すぎて のカスタマイズと拡張性の範囲がない場合は、すべてのコードを のいくつかのコンポーネントでコーディングすることを選択できます。
最終的には、通常、あなたがレイヤー&コンポーネントを編成することができ、戦略的な建築&設計が必要です。