[SPRING] Spring의 계층 구조를 사용하고 객체 지향 구조를 따르는 법?

Spring의 계층 구조를 사용하고 객체 지향 구조를 따르는 법?

나는 봄과 그 계층 구조 (컨트롤러, 서비스 및 DAO)

@Controller("userController")

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

@Repository("userDAO")

이제 나는 이처럼 계층화 된 구조로 어떻게 훌륭한 OOPS 기법을 사용하여 큰 프로젝트를 만들 수 있는지 혼란 스럽습니다. (현실 세계는 더 복잡한 비즈니스 로직을 가지고 있으며 일반적으로 제공되는 샘플 애플리케이션입니다.) 또한이 스프링 트랜잭션과 프레임 워크에서 제공하는 다른 기능을 사용하려고합니다. 어떤 사람들은 저를 도와 주거나 의심의 여지가있는 오픈 소스 프로젝트를 참조 할 수 있습니까?

해결법

1. ==============================

   1.요약하면

   요약하면

   계층화 된 아키텍처는 거대하고 복잡해질 때 코드 유지 관리 및 일관성을 완화합니다.

   기억해야 할 사실은 구현을하기 전에 적절한 소프트웨어 설계를하는 것입니다.

   상세히

   아래에서는이 토론을위한 ERP 응용 프로그램의 예를 제공하기 위해 최선을 다하고 있습니다. ERP가 비즈니스 로직의 복잡성을 파악하기에 충분한 규모의 프로젝트라고 생각하십시오.

   아래 설명은 Spring (또는 다른 프레임 워크)에서 계층화 된 프로젝트 구조를 이해하고 사용하기위한 아이디어가 필요한 모든 개발자를위한 설명입니다.

   그러나 이것들은 따라야 할 규칙이 아니라 이용 될 모범 사례입니다. :) 1. 데이터 액세스 레이어 - 모델 / 도메인 객체

   여기에는 실제 테이블을 클래스에 매핑하는 것이 포함됩니다.

   2. 데이터 액세스 계층 - 저장소

   여기에는 SELECT, INSERT, UPDATE 및 DELETE SQL을 사용하는 데이터베이스에 대한 간단한 CRUD만이 포함됩니다. Spring Data JPA와 함께 Spring의 저장소 패턴을 사용할 수 있습니다.

   주요 사항 : 논리가 고도의 데이터 집약적 인 경우가 아니면이 계층에 복잡한 논리를 쓰지 마십시오.

   이 경우 복잡한 쿼리 문을 수행하는 하나 이상의 함수를 작성해야 할 수 있습니다. (바람직하게 JPQL에서)

   3. 서비스 계층

   이것은 여러 연결되지 않은 (자식 - 부모가 아닌) 도메인 모델과 관련된 복잡한 비즈니스 논리를 넣어야하는 곳입니다. 이들은 웹 컨트롤러 및 나머지 API 컨트롤러에서 재사용됩니다.

   일관성을 유지하고 보안을 구현하기 위해 도메인 모델에 작성된 모든 비즈니스 로직을이 계층에 랩핑하는 것이 좋습니다.

   이러한 논리를 다른 모델 논리와 함께 실행해야하는 경우 서비스 계층 내에서 이러한 논리를 순서대로 호출해야합니다. 예를 들어.

   복잡한 비즈니스 논리의 기타 예제

   그런 다음 Spring AOP를 사용하여 CustomerOrderService.ReleaseCustomerOrder에 바인드 된 SupplyChainService라는 서비스를 작성하면됩니다.

   4. 컨트롤러

   컨트롤러는 웹 컨트롤러와 REST 컨트롤러의 두 가지 범주로 나눌 수 있습니다. 웹에서 호출 할 때와 API 레벨에서 호출 할 때 동일한 논리가 필요할 수 있기 때문에이 계층에는 비즈니스 로직을 구현할 필요가 없습니다.

   이 답변에서 OOP 원칙을 다루지 않은 분야를 보여준 SO 커뮤니티 덕분에

2. ==============================

   2.Spring 애플리케이션 디자인과 OOD는 상호 배타적이지 않습니다.

   Spring 애플리케이션 디자인과 OOD는 상호 배타적이지 않습니다.

   일반적인 Spring (MVC) 애플리케이션의 구조는 다음과 같습니다.

   이러한 각 객체를 설계하는 동안 원하는 OOD 접근 방식을 따를 수 있습니다.

   언급 한 OOD 예제에서는 다음과 같이 내 응용 프로그램을 디자인합니다.

   편집 : 여기에 내가 대학을 위해 쓴 예제 프로젝트를 찾을 수 있습니다. 그것은 C 레이어의 의존성을 최소화해야한다는 요구가 있었기 때문에 마지막 세 점에서 설명했던대로 @Controller와 @Service 사이에 추가 레이어를 구현합니다. 개념은 여전히 ​​적용됩니다.

3. ==============================

   3.서로 상호 운용 할 수있는 두 가지 개념을 이해하려고합니다.

   서로 상호 운용 할 수있는 두 가지 개념을 이해하려고합니다.

   계층화 된 아키텍처

   레이어 아키텍처는 업계의 아키텍처 스타일 중 하나입니다. 여기에는 특정 로직을 수행하는 별도의 레이어가 있습니다. 우리는 프리젠 테이션 레이어, 비즈니스 레이어 및 데이터 서비스 레이어를 가지고 있습니다. 이를 응용 프로그램의 가로 분할이라고합니다. 애플리케이션이 수직으로 슬라이스되는 Service Oriented / Component 기반 아키텍처와 같은 다른 아키텍처 스타일이 있습니다.

   자동 예약 프로세스가 있다고 가정 해 보겠습니다. 일반적으로 계층화 된 아키텍처 디자인 (수평 슬라이싱)을 사용하는 경우 필요한 작업을 수행 할 수있는 다른 레이어가 있습니다. 그러나 수직 슬라이싱에 관해서는 예약, 고객 관리, 기금 관리와 같이 응용 프로그램의 다른 항목을 식별합니다. 우리는 이러한 구성 요소를 구현하고 예약 응용 프로그램을 구축하기 위해 서로 통신합니다. 여기서 기억해야 할 점은 내부 구성 요소가 동일한 계층화 된 아키텍처를 유지할 수 있다는 것입니다.

   수확량 개념

   OOPS 개념은 객체 지향 방식으로 응용 프로그램을 디자인하는 데 도움이됩니다. 아키텍처 스타일을 확인하고 나면 쉽게 유지 관리 할 수있는 확장 가능한 방식으로 애플리케이션을 구현해야합니다. 따라서 서로 다른 구현 방법론을 사용합니다. OOPS가 있습니다. 더 나은 방법으로 응용 프로그램을 구현하는 데 도움이되는 디자인 원리 중 일부를 제안합니다

   SOLID 참조

4. ==============================

   4.제 생각에, 당신은 여기서 잘못된 질문을하고 있습니다. 계층화 된 아키텍처는 본질적으로 객체 지향이 아니므로 객체 지향 실습을 사용하여 (일부) 가능하거나 심지어 권장 할 만하지만 그 자체로 목표가되어서는 안됩니다. 자전거를 타는 데있어 최고의 트럭 운전 습관을 어떻게 사용하는지 묻는 것과 비슷합니다.

   제 생각에, 당신은 여기서 잘못된 질문을하고 있습니다. 계층화 된 아키텍처는 본질적으로 객체 지향이 아니므로 객체 지향 실습을 사용하여 (일부) 가능하거나 심지어 권장 할 만하지만 그 자체로 목표가되어서는 안됩니다. 자전거를 타는 데있어 최고의 트럭 운전 습관을 어떻게 사용하는지 묻는 것과 비슷합니다.

   왜 계층화 된 아키텍처가 객체 지향이 아니라고 말하고 있습니까? 글쎄, 우리가 알다시피, 객체 지향 디자인을 구별하는 3 가지 원칙, 즉 캡슐화, 상속 및 다형성이 있습니다.

   마지막 두 가지는 디자인 선택에 따라 달라질 수 있지만 계층화 된 아키텍처는 캡슐화의 반대입니다.이 접근 방식의 본질 상 데이터 ( "DTO")와 논리 ( " 서비스").

   나에게 잘못된 말을하지 마라.이 접근 방식이 객체 지향적이지 않다는 사실이 그것과 관련된 문제가 있다는 것을 의미하지는 않는다. 그리고 그 반대의 경우, "객체 지향"은 "좋은"과 동의어가 아니며, 프로그래머의 도구 상자에있는 많은 도구 중 하나이며, 다른 도구와 마찬가지로 다른 것보다 몇 가지 문제를 해결하는 데 더 적합합니다.

   계층화 된 아키텍처는 많은 실제 기술 엔지니어링 문제를 성공적으로 해결하는 데 사용할 수있는 좋은 디자인 패턴입니다. 자체적으로 모범 사례를 사용할 수 있고 사용할 수 있어야하며, 해당 집합에는 OOP의 대응 항목과 일부 교차 부분이있을 수 있지만 두 항목은 확실히 동일하지 않습니다.

from https://stackoverflow.com/questions/34429832/how-to-use-layered-architecture-of-spring-and-still-follow-object-oriented-struc by cc-by-sa and MIT license