spring - 5일차

Spring Class 별 역할

---

Controller

• 화면(view)과 비지니스 로직(Model)을 연결하는 다리 역할 (MVC를 기반으로 하고 있다.)
• => 화면에서 /aaa 로 가줘! 하면 Controller는 /aaa를 받아들여 해당 주소로 이동
• 자세하게 구분을 하면 Front Controller와 Controller로 구분 할 수 있다
   - Front Controller : 사용자의 모든 요청을 전달 받는 곳
   - Controller : 요청에 따라 적절한 view  페이지 or 적절한 컨트롤러 호출
• @Controller를 사용해 해당 클래스가 Controller 인 것을 알림
• URL이 아닌 URI로 요청을 받는다
  (위치로 찾아가게 하는 것이 아니라 아이디 맵핑을 한다 즉, 사용자에게 파일이름, 위치 노출이 없다)

• CLI, HTTP요청, HTML 처리 등을 담당
• HTML 요청처리 + 렌더링 알고있는 웹 계층
• MVC (Model / View / Controller) → presentation 계층에 속함

URL mapping → 특정 메서드가 해당 URL로 요청이 올 때마다 호출됨 (@app.route(/url)) 위의 계층을 뜻함

spring ➡️  @Controller 어노테이션 사용 (*어노테이션 : 자바 소스코드에 추가하여 사용할 수 있는 메타데이터의 일종)

 

 Service

• Controller에서 넘어온 요청을 알맞은 정보로 가공한다. 즉, '비지니스 로직'을 수행한다고 표현한다
• 비지니스 로직을 수행하고, DB에 접근하는 DAO를 이용해 결과값을 받아온다
  (DAO => 단순하게는 페이지, DB정보를 불러오는 것이고, 간단한 Service의 경우 DAO는 큰 차이가 없다
  쉽게는 MySQL 서버에 접근하여 SQL문을 실행하는 객체)

• Business 논리계층 : 유효성검사 및 계산을 포함
• application이 수행해야하는 도메인과 관련된 작업담당
• 입력/저장된 데이터를 기반으로 계산
• Presentation 계층에서 받은 데이터의 유효성 (Validation)검사
• Data Access 종류를 결정

서버 프로그램의 복잡성 증가 → 비즈니스 로직 수행을 위한 별도의 계층(layer) 필요 유능한 프레임워크 사용 → Presentation, Data Access 계층 비중 줄이고 Domain 비중 증가 ✅

spring ➡️  @Service 어노테이션 사용

 

 

Repository

• Entity에 의해 생성된 DB에 접근하는 메서드들을 사용하기 위한 인터페이스
• Entity를 사용해 DB구조를 만들었다면, CRUD정의를 어떻게 할 것인지를 정의하는 계층

• DAO 계층
• 데이터베이스 / 원격서비스의 ‘영구데이터 관리방법 분류데이터’ 접근계층

데이터베이스 or 데이터소스(데이터를 저장) → 대부분 서버 외부에 별개로 존재 Data Access 계층 : 데이터소스와 소통을 해줌

spring ➡️  @Repository 어노테이션 사용

 

느슨한 결합 (Decoupled Architecture)

• FE와 BE 분리
• FE와 BE의 코드는 분리되고, 서로 통신은 가능하지만 각각 자체 서버 인스턴스가 있다
  (주의! 이때 BE는 headless 설정의 일부로, API를 통해서만 data를 제공하고, 그 어떤 리소스도 프론트와 공유해서는 안된다 - REST API의 개념?)
• 통신방법
  1. FE에서 BE에 요청을 보내고 응답을 처리
  2. 웹 소켓을 통해 통신을 구축 후 BE 데이터 통신