이력서와 포트폴리오를 정리하면서 그동안 학원에서 배웠던 개념들이 잘 정리되지 않음을 느꼈다.
그래서 이참에 정리해보려고 한다.
1. MVC 패턴
Model - View - Controller 의 약어.
주로 GUI 기반의 애플리케이션 개발에 사용된 디자인 패턴.
※ GUI (Graphical User Interface) 란,
사용자가 컴퓨터, 휴대용 장치 및 기타 기기와 같은 전자 장치와 상호작용할 수 있는 인터페이스이다.
아이콘, 메뉴 및 기타 시각적 표시기 표현을 사용하여 정보 및 관련 사용자 컨트롤을 표시한다.
화면과 데이터 처리를 분리해 코드 간의 종속성을 줄이고 요소 간의 역할을 명확하게 하여
코드 분리가 쉽고 협업을 용이하게 함.
즉, 화면단과 데이터 처리를 나눠서 코드를 설계하는 패턴이 MVC 패턴인 것.
MVC 장점 = 유지보수 용이.
1. 디자이너와 개발자의 분업이 가능하며 확장면에서 용이함.
2. 단순하고 직관적.
3. 코드 재사용 증가.
4. Model, View, Controller 가 분리되어 있어, 필요한 부분만 쉽게 수정할 수 있음.
(1) Model
데이터 처리 영역.
데이터 구조를 표현하는 Entity와 Dto, (초기에는 Entity와 Dto를 결합한 Vo(Value Object) 형태로 사용함.)
DB와 연동하여 데이터 저장 및 검색, 수정, 삭제하는 DAO (Data Access Object)로 구성됨.
실무에서는 Controller의 비중을 줄여주기 위해 사용자에게 제공할 비즈니스 로직을 기능으로 구현한 Service 단도 사용됨.
Model은 View와 Controller에 의존하지 않아야 함.
(2) View
사용자에게 보이는 화면. 흔히 UI(User Interface) 라고 부름.
Controller로부터 전달된 데이터의 출력과 HTML, CSS, JS 등을 통해 화면의 디자인을 처리함.
모델, 컨트롤러와의 종속성 없이 구현해야 함.
(3) Controller
모든 사용자 요청을 컨트롤러에서 우선적으로 받아들여 처리함.
들어온 요청을 특정 뷰를 지정하여 보내야 하기에 뷰와 종속관계가 발생할 수 밖에 없는 구조임.
따라서 프로그램의 규모가 커질수록 컨트롤러의 역할이 커져 복잡해지고 관리가 어려워짐.
이러한 부하를 줄여주고 유지보수를 보다 용이하게 하기 위해 실무에서 Service 단이 많이 사용됨.
1-1. Spring에서의 MVC
- Model View Controller에 필요한 구조는 모두 내부에 있다.
- 모든 요청은 내부에 있는 DispatcherServlet이 받는다.
1. 받은 요청 url이 controller에 등록된 것인지 urlMapper에게 확인한다.
2. 없는 url이면 404 / 있으면 맵핑된 메서드 실행.
3. 맵핑된 메서드 실행 후 뷰페이지 경로 반환.
4. DispatcherServlet이 viewResolver(api class)에게 뷰페이지 경로를 전달하여 뷰페이지를 생성하고 실행하도록 함.
2. JSP
JSP (Java Server Pages) 는 HTML 내에 직접 자바코드를 삽입하여 웹서버에서 동적으로 웹 페이지를 생성하는 웹어플리케이션 도구.
(톰캣과 같은 웹 어플리케이션 서버(WAS) 필요함)
JSP가 실행되면 Java Servlet으로 변환되며, 웹 어플리케이션 서버에서 동작되면서 필요한 기능을 수행.
그렇게 생성된 데이터를 웹페이지와 함께 클라이언트로 응답한다.
JSP 동작 과정
1. 브라우저가 웹 서버에게 JSP에 대한 요청 정보를 전달한다.
2. 브라우저가 요청한 JSP가 (최초 요청시에만) JSP로 작성된 코드가 Servlet 코드로 변환됨. (Java 파일 생성)
3. Servlet 코드를 컴파일해서 실행가능한 Bytecode로 변환. (Class 파일 생성)
4. Servlet이 실행되어 요청을 처리하고 응답정보를 생성.
3. Spring 과 Spring Boot
Spring과 Spring Boot 는 모두 스프링 프레임워크를 기반으로 한 자바 웹 개발 프레임워크이나, 몇가지 차이점이 있다.
(1) Spring
스프링 프레임워크의 핵심 모듈을 모아서 만든 프레임워크.
(프레임워크 : 프로그램의 기본 뼈대와 api를 구축해놓은 미들웨어)
개발자가 직접 설정 파일을 작성하여 스프링 컨테이너를 구성하고, 필요한 빈 객체를 등록하고, 빈 객체 간의 의존성을 설정해야 함.
즉, 특정한 구성을 위해 추가적인 라이브러리와 설정이 필요함.
따라서, 스프링 프레임워크를 보다 세밀하게 제어하고자 하는 경우에 사용된다.
(2) Spring Boot
반면, Spring Boot 는 스프링 프레임워크를 보다 쉽게 사용할 수 있도록 만든 스프링 프레임워크를 기반으로 한 도구.
1) 개발자가 설정 파일을 작성할 필요 없이, 프로젝트의 설정과 라이브러리 의존성을 자동으로 처리해주는 기능을 제공.
예를 들어, Spring MVC, Spring Data JPA, Spring Security 등의 기능을 자동으로 설정하여,
개발자가 별도로 설정 파일을 작성하지 않아도 사용할 수 있음.
(xml 파일과 DispatcherServlet 파일을 다루지 않아도 되도록 속에 숨겨놓음.)
=> Spring boot는 application.properties에 프로젝트 설정을 작성함. (서버 포트, db 설정, 인코딩, jpa, 멀티파트 등..)
=> 일반 class 파일에 @ + 지정어 를 통해 class 용도를 지정함.
2) 모니터링과 관리를 위한 Acuator 기능을 제공하여 어플리케이션의 상태를 모니터링하고 필요한 조치를 취할 수 있도록 함.
3) 실행 가능한 jar 파일을 만들 수 있음.
4) 내장 서버를 제공하여 쉽게 웹 어플리케이션을 실행할 수 있음.
- 서버를 stand alone으로 쓸 수 있음.
: 이전엔 하나의 톰캣 서버(8787)에 여러 프로젝트를 올렸다면, 스프링부트는 하나의 서버에 하나의 프로젝트만.
따라서, Spring Boot는 빠르고 간단하게 스프링 어플리케이션을 개발하고자 하는 경우에 사용된다.
즉, 내가 진행한 프로젝트는 모두 Spring Boot를 사용했다는 걸 확실히 알 수 있음!
4. JDBC Template / MyBatis / JPA
JDBC(Java DataBase Connectivity) 는 Java와 DB를 연결하기 위한 Java 표준 인터페이스이다.
MySQL, MariaDB, PostgreSQL 등 다양한 DB와 연결이 가능하며,
Java 표준이기 때문에 JVM 위에서 운영되는 어플리케이션에서 자유롭게 사용할 수 있다.
(JVM(Java Virtual Machine)은 자바 가상 머신으로, 자바 프로그램 실행환경을 만들어주는 소프트웨어이다.)
기존 JDBC는 쿼리를 실행하기 전과 후의 연결 생성, 명령문 등 많은 코드를 작성해야 하고 커넥션 관리와 예외 처리 등에 불편함이 있다.
Spring JDBC는 이러한 불편함을 SQL Mapper를 통해 해결한다.
SQL Mapper는 SQL 문장으로 직접 데이터베이스를 다루는 시스템으로,
객체지향 언어인 Java의 관계형 데이터베이스 프로그래밍을 좀더 쉽게 할 수 있게 도와주는 개발 프레임워크이다.
복잡한 쿼리 등을 작성하는 데 더 효과적이지만,
SQL이 Java 코드와 분리되어 있기 때문에 객체와 쿼리문 모두를 관리해주어야 한다는 단점이 있다.
SQL Mapper에는 JDBC Template와 MyBatis, JPA가 있다.
(1) JDBC Template
JDBC Template는 스프링에서 기본으로 제공하는 jdbc api로, DAO 클래스 작업을 쉽게 처리할 수 있다.
Spring JDBC에서는 DriveManager가 하는 일들을 SQL Mapper 중 하나인 JDBC Template에게 맡겨
커넥션 열고 닫기, Statement 준비 및 실행, 닫기 등을 처리해주어 개발자는 DataSource만 제공해주기만 하면 된다는 장점이 있다.
(2) MyBatis
MyBatis는 JDBC를 통해 데이터베이스에 엑세스하는 작업을 캡슐화하고 일반 SQL쿼리, 저장 프로시저 및 고급 매핑을 지원하며,
모든 JDBC 코드 및 매개 변수 중복작업을 제거한다.
프로그램에 있는 SQL 쿼리를 Java 코드에 직접 작성하는 것이 아닌, xml 파일에 별도로 구성하여 인터페이스로 매핑하여 관리하며,
프로그램 코드와 SQL을 분리할 수 있는 장점을 가지고 있다.
MyBatis는 복잡한 쿼리나 다이나믹한 쿼리에 강하지만 비슷한 쿼리를 남발하게 되는 단점이 있다.
프로그램 코드와 SQL 쿼리의 분리로 코드의 간결성 및 유지보수성이 향상된다.
resultType, resultClass 등 Vo를 사용하지 않고 조회결과를 사용자 정의 DTO, MAP 등으로 매핑하여 사용할 수 있다.
따라서 빠른 개발이 가능하여 생산성이 향상된다.
반면, 커넥션을 자동으로 관리해주는 Spring JDBC와 다르게,
MyBatis는 SQL 쿼리 실행 전 SQL Session을 열고 실행하고 닫는 과정을 수행하기 때문에
세션을 열고 닫는 과정과 인터페이스로 관리하는 부분에서 번거롭다는 단점이 있다.
↓ 더 자세한 내용은 아래 글 참조
↓ 코드 적용은 아래 글 참조
(3) JPA
JPA (Java Persistent API) 란, Java ORM 기술에 대한 API 표준 명세로, Java에서 제공하는 API이다.
즉, JPA는 ORM을 사용하기 위한 표준 인터페이스를 모아둔 것.
JPA와 JDBC의 큰 차이점은 쿼리를 통해 DB에 접근하는 JDBC와 다르게 ORM 기술을 이용하여 객체를 통해 간접적으로 DB를 다룬다는 것이다.
ORM이란, 어플리케이션 class와 RDB의 테이블을 매핑하는 기술이다.
(RDB(Relational DataBase)는 관계형 데이터 모델에 기초를 둔 DB. Oracle을 생각하면 된다.)
객체 간의 관계를 바탕으로 RDB 테이블에 자동으로 영속화하여 SQL Mapper와 달리 쿼리로서 관리하지 않아도 된다는 장점이 있다.
=> 쿼리문을 직접 작성하지 않아도 @ + 지정어 를 사용하면 자동으로 쿼리의 역할을 수행해준다.
(자동으로 테이블 생성하고 데이터 추가, 수정, 삭제가 가능하다.)
(단, 제공하는 기능 외의 쿼리를 수행하려면 직접 쿼리를 작성해줘야 한다.)
하지만 ORM 기술의 경우 복잡한 SQL을 수행하기 힘들고 쿼리 성능의 최적화가 어렵다는 단점이 있다.
5. REST API
(1) REST
REST (Representational State Transfer) 란,
HTTP URI 를 통해 자원(Resource)을 명시하고,
HTTP Method(POST, GET, PUT, DELETE) 를 통해 해당 자원에 대한
CRUD Operation을 적용하는 것을 의미한다.
※ CRUD Operation
- Create: 생성 (POST)
- Read: 조회 (GET)
- Update: 수정 (PUT)
- Delete: 삭제 (DELETE)
- HEAD: header 정보 조회 (HEAD)
즉, 자원 기반의 구조 (ROA, Resource Oriented Architecture) 설계의 중심에 Resource가 있고
HTTP Method를 통해 Resource를 처리하도록 설계된 아키텍쳐를 의미한다.
웹사이트의 이미지, 텍스트, DB 내용 등의 모든 자원에 고유한 ID인 HTTP URI를 부여한다.
(2) REST API
REST API는 REST 기반으로 서비스 API를 구현한 것으로,
두 개의 컴퓨터가 인터넷을 통해 정보를 안전하게 교환하기 위해 사용하는 인터페이스이다.
OpenAPI는 대부분 REST API를 제공한다.
(백과 프론트에서 모두 구현 가능하며, 프론트에서 JS로 구현하는 방식이 훨씬 간편하다,,)
※ API (Application Programming Interface)
응용프로그램에서 사용할 수 있도록 운영 체제가 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스이다.
데이터와 기능의 집합을 제공하여 컴퓨터 프로그램 간 상호작용을 촉진하며, 서로 정보 교환을 가능하도록 하는 것이다.
↓ REST API 설계 규칙은 아래 글 참조
(3) RESTful
일반적으로 REST 원리를 잘 따르는 시스템을 RESTful 하다고 할 수 있다.
REST를 REST답게 쓰기 위한 방법으로, 이해하기 쉽고 사용하기 쉬은 REST API를 만드는 것을 목적으로 한다.
CRUD 기능을 모두 POST로만 처리하는 API이거나,
route에 resource, id 외의 정보가 들어가는 경우 RESTful 하지 못하다고 표현한다.
5-1. REST API 사용 이유
REST는 복잡한 네트워크에서 통신을 관리하기 위한 지침으로 만들어졌다.
REST 기반 아키텍처를 사용하면, 대규며의 고성능 통신을 안정적으로 지원할 수 있다.
또한 쉽게 구현하고 수정할 수 있다.
* 장점
1. 쉬운 사용성
REST API의 메시지를 읽는 것만으로 메시지의 의도를 확실히 파악할 수 있다.
또한 HTTP의 인프라를 그대로 사용하기 때문에 API 사용을 위한 별도의 인프라 구축이 필요하지 않다.
2. 클라이언트와 서버의 완전한 분리
클라이언트와 서버는 REST API를 이용해 정보를 주고 받는다.
따라서 서버는 클라이언트의 히스토리, 문맥을 유지할 필요가 없게 된다. (stateless: 상태 유지 안함)
=> session 보다 token으로 상태 유지
즉, 각자의 역할이 명확하게 나뉘어져 있어 플랫폼의 독립성이 확장되고 개발자의 업무량이 감소하는 효과를 가져온다.
HTTP 프로토콜 서비스라는 요구조건만 충족된다면,
더 다양한 플랫폼에서 원하는 서비스를 쉽고 빠르게 개발하고 배포할 수 있다.
3. 특정한 데이터의 명확한 표현
REST API는 헤더 부분에 URI 처리 메서드를 명시한다.
이는 특정 메서드의 세부 표현을 다양한 언어 (JSON, xml)로 작성할 수 있는 장점이 있고,
헤더 표현의 가독성이 향상되어 메시지의 의도를 쉽게 파악할 수 있다.
* 단점
HTTP 메서드를 사용해 URI를 표현하기 때문에 다양한 인프라에서 사용이 가능하지만,
메서드 형태가 제한적이다.
또한 표준이 존재하지 않다.