web-dev-qa-db-ja.com

春の階層化アーキテクチャを使用し、オブジェクト指向の構造を引き続き使用する方法は？

春とその階層構造（コントローラー、サービス、およびdao）を学びました

@Controller("userController")

@service("userService")
@Transactional(     propagation = Propagation.REQUIRED,     isolation = Isolation.DEFAULT,      readOnly = true)

@Repository("userDAO")

今、私はどのように良いOOPSプラクティス（ this のような）をこれらの階層構造で利用して大きなものにするのか混乱していますプロジェクト（実際には、通常提供されるサンプルアプリケーションよりも複雑なビジネスロジックがあります）。また、これらの春のトランザクションとフレームワークが提供するその他の機能を使用したいと思います。誰かが私を助けてくれるか、私の疑問を明確にするオープンソースプロジェクトを参照してください。

javaspringoopspring-mvcopen-source
26
Nirbhay Mishra

Springアプリケーションの設計とOODは相互に排他的ではありません。

典型的なSpring（MVC）アプリケーションの構造は次のとおりです。

  1. 1つ以上の@Controllerclasses。これらは、アプリケーションのエントリポイントです。ビジネスロジックを含めないでください。名前にもかかわらず、MVCで[〜＃〜] v [〜＃〜]としてそれらを識別します（ Model-View-Controller ）
  2. 1つ以上の@Serviceクラス。ここでビジネスロジック（BL）を開発します。 BLをここに置く利点の1つは、複数のコントローラー（@Controllerや@RestControllerなど）で再利用できることです。 MVCの[〜＃〜] c [〜＃〜]です。
  3. 1つまたは複数の@Repositoryクラス。永続層（データベース、メモリ内など）を実装します。さらに、ドメインオブジェクトを記述する@Componentsクラスのセットを実装できます。これらは、MVCの[〜＃〜] m [〜＃〜]です。
  4. @Configuration、@ControllerAdvice、およびその他のSpring構成/管理クラスなど、MVCパターンにマッピングできない他のクラス。

これらの各オブジェクトを設計する際、 [〜＃〜] ood [〜＃〜] 好きな方法を使用できます。

あなたが言及したOODの例では、次のようにアプリケーションを設計します。

  1. アクターごとに1つのビュー（@Controller）
  2. ユースケースごとに1つの@Service
  3. ドメインクラスごとに1つの@Repositoryと1つの@Component

編集：大学のために書いたサンプルプロジェクトを見つけることができます こちら 。 [〜＃〜] c [〜＃への依存を最小限に抑える必要があったため、最後の3つのポイントで説明したものを追加レイヤー（@Controllerと@Serviceの間）で実装します〜]レイヤー。概念はまだ適用されます。

9
Marco Ferrari

ここで間違った質問をしていると思います。階層化アーキテクチャは本質的にオブジェクト指向ではないため、オブジェクト指向のプラクティス（の一部）を使用することは可能ですが、それでも望ましいことですが、それ自体が目標であってはなりません。それは、自転車に乗るために最高のトラック運転慣行をどのように使用するかを尋ねることに似ています。

レイヤードアーキテクチャはオブジェクト指向ではないと言っているのはなぜですか？さて、私たちが知っているように、オブジェクト指向設計を区別する3つの原則があります：カプセル化、継承、および多態性です。

最後の2つは存在する場合と存在しない場合がありますが、設計の選択に応じて、階層化アーキテクチャは、ほとんどカプセル化のoppositeです。このアプローチの性質により、データ（ "DTO 「）ロジック（「サービス」）から。

誤解しないでください。このアプローチがオブジェクト指向ではないという事実は、何か問題があるという意味ではありません。逆に、「オブジェクト指向」は「良い」と同義ではなく、プログラマーのツールボックスにある多くのツールの1つであり、他のツールと同様に、他の問題よりも問題の解決に適しています。

階層化アーキテクチャは優れた設計パターンであり、実際のエンジニアリングの多くの問題を解決するために使用できます。使用できる、使用する必要がある独自のベストプラクティスのセットがあり、そのセットにはOOPの対応物との共通部分があるかもしれませんが、2つは確かに同等ではありません。

4
Dima

相互運用できる2つの異なる概念を理解しようとしています。

レイヤードアーキテクチャ

レイヤーアーキテクチャは、業界のアーキテクチャスタイルの1つです。これには、特定のロジックを実行するための別のレイヤーがあります。例として、プレゼンテーション層、ビジネス層、データサービス層があります。これは、アプリケーションの水平スライスと呼ばれます。アプリケーションが垂直方向にスライスされるサービス指向/コンポーネントベースのアーキテクチャのような他のアーキテクチャスタイルがあります。

自動化された予約プロセスがあるとします。通常、階層化されたアーキテクチャ設計（水平方向のスライス）を使用する場合、必要な作業を行うための別のレイヤーがあります。ただし、垂直スライスに関しては、アプリケーションのさまざまなエンティティを予約、顧客管理、資金管理として識別します。これらのコンポーネントを実装し、予約アプリケーションを構築するために相互通信します。ここで覚えておくべきポイントは、内部コンポーネントが同じ階層化アーキテクチャを休ませることができることです。

OOPSの概念

OOPSの概念は、オブジェクト指向の方法でアプリケーションを設計するのに役立ちます。アーキテクチャーのスタイルを特定したら、簡単に保守できる拡張可能な方法でアプリケーションを実装する必要があります。そのため、実装方法は異なります。 OOPSはそれらのうちの1つです。より良い方法でアプリケーションを実装するのに役立つ設計原則のいくつかを提案します

[〜＃〜] solid [〜＃〜] を参照してください

4
BValluri