(오우 MBC라고 적을뻔했다.)
이번 주의 테마 - ORM, SQL, MVC
ORM - 객체 관계 맵핑. OOP의 객체와 RDB의 테이블을 연결해주는 것
우리는 사실 다 관계가 있는 사이라구? - ORM과 ODM이 있다. 그중 ORM을 볼것.
- ORM: Object Relational Mapping. 객체 관계 맵핑. 쉽게 말해서 JAVA 문법으로 RDB 다루게 해주는 것.
-> JAVA는 '클래스'를 사용하고, 관계형 DB는 '테이블'을 사용한다. 즉, 둘이 동일한걸 사용하는게 아님.
-> 사용하는 대상과 문법이 다르다 - 이를 '패러다임의 불일치' 라고 한다.
->그래서 객체지향 언어와 관계형 DB 사이의 불일치 해결을 위해 나온 것.
-> ORM을 통해 객체 간의 관계를 자동으로 생성하여 불일치를 해결한다.
ORM을 사용한 장점?
-
백엔드 개발자가 쿼리문 등에 더 신경써야 하는 주객전도 현상을 줄여주었다 - 객체지향 코드로, 로직에 집중하게 도와줌.
-
재사용 및 유지보수의 편리함은 말할것도 없음.
ORM의 단점!
-
완벽히 ORM으로만 서비스 할 수는 없다. ODM이라는 것이 있음. MongoDB 같은 것도 병행하게 될것.
-
ORM의 객체지향적 장점을 활용하기 어려운 시스템 구조에서는 큰 효율을 보이지 못한다.
SQL? NoSQL?
- Structured Query Language. 관계를 다루기 위한 언어. 관계형 DB의 데이터를 다루기 위해서 사용되는 쿼리 언어이다.
-> SQL을 사용하는 DB를 SQL DB, 반드시 SQL을 사용하지는 않는 DB를 NoSQL DB라고 하는데,
-> 사실상 MongoDB같은 ODM 타입의 NoSQL DB에서는 못쓴다고 보는게 타당하다.
-> SQL을 쓰려면 기본적으로 테이블의 컬럼이 고정되어 있어야 하는데, NoSQL은 컬럼값부터 바꿔버릴수 있기 때문 -> 쓰기가 곤란하다.
MVC - 왜 우리는 주특기를 가장 모르는걸까. 모델과 뷰와 컨트롤러의 삼위일체.
- Model View Controller - 소프트웨어 디자인 패턴의 일종. 애플리케이션을 세 가지 역할로 구분한 개발 방법론.
- MVC 패턴이 적용되지 않은 Legacy PHP 같은걸 보면, 여기저기 View니 DB니 Service니 여러 내용들이 산재되어 있음.
PHP는... JAVA보다도 더 맛대가리 없는(진유진 매니저님 표현) 이므로 관심은 두지 않는 것이 좋다.
모델은 뭐고 뷰는 뭐고 컨트롤러는 뭔데요? 컨트롤러 이거 아니에요? 🎮
응 아니야. 입벌려 MVC 들어간다.
▶Model: 데이터와 정보의 가공을 책임지는 부분!
▶모델은 데이터베이스, 처음에 정의하는 상수, 초기화 값, 변수 등 어플리케이션의 정보와 데이터를 나타낸다.
<모델의 규칙>
-
모델은 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야 한다.
-
모델은 뷰나 컨트롤러에 대해 어떤 정보도 알면 안된다! 뷰가 어떻게 나오든 컨트롤러가 뭘 다루든 모델은 몰라야 한다.
-
변경이 일어나면 변경 통지에 대한 처리 방법을 구현해야 한다 - 아니 뭔 소리에요?
-> 이를테면 픽셀이 바뀌면 바뀌었단 alert, 데이터 송수신에 성공했으면 했다, 실패했으면 했다는 alert를 반환하는 코드가 들어있어야 한다는 것.
▶View: 말 그대로 화면. 프론트가 다루는 영역. 유저 인터페이스를 의미!
▶뷰는 사용자와 상호작용을 하면서, 컨트롤로부터 받은 모델의 결과값을 사용자에게 화면으로 출력하는 일을 수행.
<뷰의 규칙>
-
뷰는 모델이 가지고 있는 정보를 저장해선 안된다 - 네? 그러면 세션 스토리지 같은건 어떡해요? 로그인 세션 정보 같은거 저장 하잖아요.
-> 세션정보나 쿠키같은 '응답값'은 당연히 저장해도 되는데, 세션이나 쿠키가 '생성되는 과정'에 대해서는 얘가 저장하면 안된다는 얘기! -
뷰는 다른 구성요소들을 몰라야 한다 - 모델이나 컨트롤러가 뭘 하고 있는지를 몰라야 합니다. 그냥 받아서 그대로 보여주기만 하면 됨!
-
변경이 일어나면 변경 통지에 대한 처리 방법을 얘도 구현해야 한다 - Model이 반환하는 alert를 얘가 받아서 화면에 띄워줘야 함!
▶Controller: Model과 View의 연결다리. 얘는 다른 애들을 알아야 함!
▶컨트롤러는 서로의 존재를 모르는 모델과 뷰 사이를 연결하는 중재자 역할을 한다. 따라서 얘만큼은 모델과 뷰에 대해 알아야 한다!
<컨트롤러의 규칙>
-
모델과 뷰에 대해서 알고있어야 한다!
-
모델이나 뷰의 변경을 모니터링 하면서 계속 확인해야 한다.
※주의해야 할게, 이 MVC에서의 Controller는 Spring에 있는 그 Controller를 말하는게 아니다!
물론 걔도 역할은 비슷할지언정, 동일한 것을 나타내는건 아님!
그러면 Spring의 MVC와는 뭐가 다를까나?🤔
-
Spring MVC는 웹 MVC 프레임워크이면서, Spring 프레임워크의 하위 모듈이다.
(Spring boot가 아니라 그냥 Spring의 하위 모듈!)
-> 모델 뷰 컨트롤러를 명확하게 분리해서, 매우 유연하고 확장성이 좋다는 특징을 가진다. -
내가 기억하는 그 'Dispatcher servlet이 request를 받아서 handler mapping을 하고...' 하는 이 과정, 이래저래 쌈바춤을 추는(진유진 매니저님 표현ㅋㅋㅋ) 그 일련의 모든 과정들이 Spring MVC의 동작 과정임!
-
요새는 View Resolver를 사용하지 않는 특정 어노테이션을 써서 데이터만 쏴주기도 한다고 -> 이게 바로 우리가 쓰는 RestController야!
이거 왜 해요? -> 프론트와 백의 구분을 좀더 명확하게 하자고. 백은 API만 만들고, 뷰는 뷰만 만들자는것.
그러니 데이터만 주겠다는 것임. 뷰에 관한 모든건 프론트가 알아서 하라고. 이 데이터 줄테니 님들이 알아서 뷰 렌더링 하라고.
그래서 서버사이드 렌더링을 점점 안하는 추세인듯? 🤔
@Controller
Model 객체를 만들어 데이터를 담고, View를 찾는 역할을 한다.
-> 별거 아니고 얘는 HTML을 그대로 반환해주는 것임. 뭐 데이터를 어디 싸서 보내주고 그런게 아님.
-> 얘는 주로 JSP랑 Thymeleaf같은 라이브러리를 쓸때 많이 사용하는 어노테이션임. HTML을 그대로 반환해주기 때문에.
@RestController
@Controller + @Responsebody인 어노테이션. View 대신 Json 형태의 데이터를 반환해줌!
@RequestMapping
특정 요청 URL에 대한 HTTP 메소드를 지정해줄때 사용함. Class 위에 이걸 사용해주면, prefix처럼 사용할 수 있다.
이를테면 @RequsetMapping(value="/api") 라고 쓰면, 내가 이 다음에 맵핑할 모든 URL의 앞부분에 /api를 자동으로 붙여주겠다는 말!
- 아 RequsetMapping 너무 길어요! -> @GetMapping, @PostMapping 등등으로 분리!
여기서 주의점 - 요청 URL이 같으면 같은 HTTP메소드(@~~Mapping)를 쓸수 없다!
이를테면, @GetMapping("/hello") 얘만 두번 사용할 수 없다는 것! 그냥 중복코드에 지나지 않기 때문.
-> GetMapping 쓰려면 다른 URL을 쓰던지, /hello를 사용하려면 다른 메소드를 쓰던지 해야한다.
-> 이건 JAVA 메소드 이름만 다르게 해봤자 소용없다. Mapping방식이 아예 다르거나 URL이 달라야 한다!
