한주간의 이야기
주특기 입문 주차가 끝나고 숙련주차가 시작된 한주였다.
본격적으로 공부량이 많아지고 어려운 개념들이 늘어나자 매일 열심히 작성하려고 했던 TIL을 작성할 시간도 없어지기 시작했다.
숙련주차에서 학습한 내용중 JPA를 중요하게 다뤘는데, 며칠 배운다고 완벽하게 마스터 할 수 있는 것도 아니거니와 추상적인 개념들이 나오다 보니 부쩍 어렵게 느껴졌다.
Entity 설계, 연관관계 설정 등등.. 여러 블로그를 찾아보고 강의를 다시 들어봐도 애매모호~하다.
계속 코드를 치면서 연습하면서 익혀가야 할 것 같다.
그리고 금요일부터 주특기 심화주차가 시작되었다. 이번주 과제는 팀원들끼리 해결해야하는데 깃허브로 협업을 해야하는 것에 큰 걱정이 있다..
사실 기능을 나누는 것부터 시작해서 Entity 설계등 처음부터 우당탕탕 해서 제대로 과제를 진행할 수 있을까 걱정이 많지만, 팀원들 모두가 열심히 하고 있으니 잘 해낼 수 있을 거다!!
이번에도 후다닥 과제 끝내고 공부할 시간을 만들 수 있었으면 좋겠다.
💡이번주 키워드
ORM
Persistence란?
Persistence(영속성)이란 데이터를 생성했던 프로그램이 종료되더라도 데이터는 사라지지않는 것을 의미한다.
예를들어, 일정관리 어플리케이션을 사용하다 종료하더라도 저장했던 일정들이 사라지지않고 그대로 남아있는 것으로 보아 데이터의 영속성이 유지되고 있는 것을 알 수 있다.
이러한 영속성 있는 데이터들을 사용하기 편하게 해주는 것이 Persistence Framework인데, Persistence Framework의 종류로는 SQL Mapper, ORM이 있다.
Persistence Framework
DB와의 연동되는 시스템을 빠르게 개발하고, 안정적인 구동을 보장해주는 프레임워크이다.
SpringBoot와 DB를 이어주는 역할을 한다. (영속성을 부여해주는 역할)
Persistence Framework를 사용하는 이유로는 아래와 같은 장점들이 있다.
-
재사용 및 유지보수에 용이하다.
데이터 베이스에는 MySQL, MariaDB, PostgreSql 등 여러가지 종류가 있는데, 만약 DB를 교체하더라도 Persistence Framework는 그대로 두고 DB만 교체하면 되기때문에 재사용 및 유지보수에 용이하다. -
코드가 직관적이다.
Persistence Framework가 없다면 SpringBoot와 DB를 연결하는 부분을 개발자가 전부 관리를 해야만 한다.
ORM: Object Relation Mapping
- 쿼리없이 Object와 DB테이블을 매핑한다. (ex. student객체와 student테이블을 매핑)
J* ava 함수를 사용하면 자동으로 SQL이 만들어진다. - 매핑: DB테이블 <-> 객체
- 단점
- 복잡한 쿼리를 자바 메서드 만으로 해결하는 것이 불편하다.
- 복잡한 쿼리를 자바 메서드 만으로 해결하는 것이 불편하다.
JPA
Java Persistence API의 약자인 JPA는 Java ORM 표준이다.
위에서 말했듯 ORM은 객체지향 프로그래밍 구조에서 사용될 수 있는 구조이고, JPA가 Java영역에서의 ORM의 표준을 제시하는 Interface이다.
이 외에도 JPA는 내부적으로 영속성 컨택스트를 생성하여 Entity를 관리한다.
변경 감지를 통해서 개발자가 Entity를 수정하기만 해도 그에 맞는 쿼리가 생성되고, 쓰기 지연 방식을 통해서 Query 저장소에 있는 Query들을 한번에 flush 시킴으로써 Connection을 최소화해 서비스 성능을 향상시킬 수 있다.
JPA는 Interface라서 이를 구현할 구현체가 필요한데, 대표적인 구현체가 Hibernate이다.
Hibernate
Java ORM(JPA)구조에서 개발자가 따로 Query를 작성하지 않아도 되는 이유는 이 Hibernate가 내부적으로 Query를 생성하고 JDBC API를 호출하기 때문이다.
다만 생성되는 Query가 모든 개발환경에 적합하다고 볼 수 없고, 개발자 본인이 능동적으로 쿼리를 수정할 필요가 있는데 이때 Spring Data JPA가 사용된다.
Spring Data JPA
JPA를 한단계 더 추상화시킨 Repository라는 개념을 제시하여 개발자가 Respository Interface에 JpaRepository를 상속하기만 하면 사용시점에 Spring이 알아서 구현화 된 객체를 주입해준다.
또한 Respository Interface 내부에서 작성된 메서드 또한 Spring이 적합한 Query를 생성하여 전송하도록 해준다.
Query annotation을 통해서 개발자가 생성한 Query 문을 전송할 수도 있다.
SQL
데이터 베이스(DB)
데이터베이스(Database)는 "데이터의 집합"이라고 한다.
데이터 베이스에는 일상생활의 대부분의 정보가 저장되고 관리된다.
DBMS
DBMS (Database management System)는 데이터 베이스를 관리하고 운영하는 소프트웨어이다.
- 대용량의 데이터를 사용하고 저장, 관리 할 수 있다.
- 공유개념, 동시에 다른 사용자가 공유할 수 있다.
데이터베이스는 여러명의 사용자나 응용 프로그램과 공유하고 동시에 접근이 가능해야한다. - DBMS 분류로는 계층형, 망형, 관계형, 객체지향형, 객체관계형 등이 있다.
- 대표적 관계형 데이터베이스(RDBMS)로는 Oracle, MySQL, MariaDB, SQLite, PostgresSQL 등이 있다.
SQL이란?
SQL(Structured Query Language)은 이러한 DBMS에 데이터를 구축, 관리하고 활용하기 위해서 사용되는 언어이다.
간단히 말해서 "SQL"은 데이터베이스 용 프로그래밍 언어이다.
SQL은 구조화된 쿼리 언어이며, 데이터베이스에 쿼리를 보내 원하는 데이터를 가져오거나 삽입할 수 있다.
쿼리(query)란?
쿼리(Query)란 쉽게 이야기해서 데이터베이스에 정보를 요청하는 것을 말한다.
쿼리(Query)는 웹 서버에 특정한 정보를 보여달라는 웹 클라이언트 요청(주로 문자열을 기반으로 한 요청)에 의한 처리이다. 쿼리(Query)는 대개 데이터베이스로부터 특정한 주제어나 어귀를 찾기 위해 사용된다.
MVC
MVC패턴이란?
MVC란 Model-View-Controller의 약자로 애플리케이션을 세 가지 역할로 구분한 개발 방법론이다.
아래의 그림처럼 사용자가 Controller를 조작하면 Controller는 Model을 통해 데이터를 가져오고 그 데이터를 바탕으로 View를 통해 시각적 표현을 제어하여 사용자에게 전달하게 된다.
이러한 패턴을 성공적으로 사용하면, 사용자 인터페이스로부터 비즈니스 로직을 분리하여 애플리케이션의 시작적 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있는 애플리케이션을 만들 수 있게 된다.
위의 개념을 Web에 적용하면
- 사용자가 웹사이트에 접속 (Users)
- Controller는 사용자가 요청한 웹페이지를 서비스하기 위해서 모델을 호출 (Manipulates)
- Model은 데이터베이스나 파일과 같은 데이터 소스를 제어한 후 그 결과를 Return
- Controller는 Model이 리턴한 결과를 View에 반영 (Updates)
- 데이터가 반영된 View는 사용자에게 보여짐 (Sees)
모델(Model)
데이터를 가진 객체를 모델이라고 한다.
데이터는 내부의 상태에 대한 정보를 가질 수도 있고, 모델을 표현하는 이름 속성으로 가질 수 있다.
모델의 상태에 변화가 있을 때 컨트롤러와 뷰에 이를 통보한다.
이와 같은 통보를 통해 뷰는 최신의 결과를 보여줄 수도 있고, 컨트롤러는 모델의 변화에 따른 적용 가능한 명령을 추가, 제거, 수정할 수 있다.
- 사용자가 편집하길 원하는 모든 데이터를 가지고 있어야만 한다.
- 뷰나 컨트롤러에 대해서 어떠한 정보도 알지 말아야 한다.
- 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야 한다.
뷰(View)
View는 클라이언트 측 기술은 HTML/CSS/Javascript들을 모와둔 컨테이너이다.
사용자가 볼 결과물을 생성하기 위해 모델로부터 정보를 얻어온다.
- 모델이 가지고 있는 정보를 따로 저장해서는 안된다.
- 모델이나 컨트롤러와 같이 다른 구성 요소를 몰라야 한다.
- 변경이 일어나면, 변경 통지에 대한 처리방법을 구현해야 한다.
컨트롤러(Controller)
사용자가 접근한 URL에 따라 사용자의 요청사항을 파악한 후에 그 요청에 맞는 데이터를 Model을 의뢰하고, 데이터를 View에 반영해서 사용자에게 알려준다.
모델에 명령을 보냄으로써 뷰의 상태를 변경할 수 있으며, 컨트롤러가 관련된 모델에 명령을 보냄으로써 뷰의 표시 방법을 바꿀 수 있다.
- 모델이냐 뷰에 대해서 알고 있어야 한다.
- 모델이나 뷰의 변경을 모니터링해야 한다.
MVC패턴의 장단점
비즈니스 로직과 UI로직을 분리하여 유지보수를 독립적으로 수행가능하며, Model과 View가 다른 컴포넌트들에 종속되지 않아 애플리케이션의 확장성, 유연성에 유리하다.
그러나 Controller에 다수의 Model과 View가 복잡하게 연결되어 있는 상황이 발생할 수도 있다.
