서버는 “새로운 데이터를 처리하는 부분”, “서비스 로직을 처리하는 부분”, “기존의 데이터를 이용하는 부분” 으로 되어 있습니다.
@Controller //이 자바 객체가 컨트롤러 역할을 하는 객체라는 것을 알려주는 어노테이션
public class ContentController {
//(일반적으로)각각의 레이어는 자기와 인접한 레이어와 직접 소통
//이 경우 ContentService객체를 가지고 있어, 컨트롤러 단에서 서비스 단으로 새로 받아온 데이터를 전달 or 서비스 로직을 호출 가능
//예를들어 #2-1 처럼
private final ContentService contentService;
@GetMapping("/content/{contentId}") //특정 요청에 호출될 메서드를 지정해주는 어노테이션 (flask의 @app.route(”/”)와 비슷)
public Content getContent(@PathVariable Long contentId) { //해당 메서드에 넘기는 인자값을 손쉽게 넘기도록 함 --> 이 어노테이션이 있으면, 자동으로 일치하는 변수값을 메서드 호출되는 시점에 같이 넘겨줌(JVM 같은???)
Content content = contentService.getContent(requestDto); //#2-1
return "/contentPage";
}
//위의 어노테이션(@GetMapping("/content/{contentId}"))과 다른 이유?
//HttpMethod에 따라서 다른 Controller 메서드를 연결해줄 수 있기 때문 --> 같은 주소로 온 GET 요청과 POST을 나눠서 각각 처리하기에 용이
@PostMapping("/content")
@ResponseBody//@PostMapping("/content")와의 차이? 뷰까지 같이 반환하느냐, 혹은 JSON 형식으로 데이터만 반환하느냐의 차이
public Content createContent(@RequestBody ContentRequestDto requestDto) {
Content content = contentService.createContent(requestDto);
return content;
}
}
@Service //이 자바 객체가 서비스 역할을 하는 객체라는 것을 알려주는 어노테이션
public class ContentService {
private final ContentRepository contentRepository; //인접한 계층인 Repository 객체를 가짐
public ReturnDto getContent(Long id) {
ReturnDto returnDto = contentRepository.findById(id);
return returnDto; //인접한 계층으로 데이터를 전달
}
public Content createContent(ContentRequestDto contentRequestDto) {
Content content = new Content(contentRequestDto);
contentRepository.save(content);
return content;
}
}
@Repository //이 자바 객체가 서비스 역할을 하는 객체라는 것을 알려주는 어노테이션
public interface ContentRepository extends JpaRepository<Content, Long> { //우리가 직접 사용하게 될 부분!!
}
단순 반복작업부분이 많았던 Controller와 Repository쪽을 개발 관점에서 매우 쉽고 편하게 처리해줘, 가장 중요한 핵심 비즈니스 로직인 Service 레이어에 더 집중 할 수 있도록 하게 해준다.
소프트웨어 아키텍처 패턴: https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch01.html
레이어드 아키텍처 패턴: https://jojoldu.tistory.com/603