devkobe24.com
Algorithm
2024
Archive
AWS
CPP_DS
CS
DataStructure
Database
HackTheSwift
Java_archive
Leet-Code
MySQL
Network_archive
OS
Read English Book
SQL
Spring & Spring Boots
TIL
Web
Backend
AWS
CS
DB
ENG
Math
Post
Spring
TIL
Java
Java多識
Java
Network
2024
SQL
SQL
2024
Home
Contact
Copyright © 2024 |
Yankos
Home
>
Archive
> Spring & Spring Boots
Now Loading ...
Spring & Spring Boots
🍃[Spring] Gradle과 Maven
Gradle. Gradle은 오픈 소스 빌드 자동화 시스템으로, 다양한 프로그래밍 언어와 프로젝트에 대해 유연한 빌드 스크립트를 제공합니다. Groovy나 Kotlin DSL을 사용하여 빌드 스크립트를 작성하며, 이는 개발자가 읽기 쉽고, 강력하며, 사용자 정의가 가능한 빌드를 구성할 수 있게 합니다. Gradle은 의존성 관리와 멀티 프로젝트 빌드를 지원하며, 이전에 실행된 작업의 출력을 캐시하여 빌드 시간을 단축시키는 증분 빌드 기능도 제공합니다. Android 개발을 위한 공식 빌드 시스템으로도 널리 사용됩니다. Maven. Maven은 Java 프로젝트의 빌드, 문서화, 보고, 의존성 관리 등을 자동화하기 위한 또 다른 오픈 소스 빌드 도구입니다. XML 형식의 pom.xml 파일을 사용하여 프로젝트 구성과 의존성을 관리합니다. Maven은 중앙 저장소에서 필요한 라이브러리와 플러그인을 자동으로 다운로드하고, 프로젝트의 라이프사이클(컴파일, 테스트, 패키징 등)을 관리하는 표준화된 방법을 제공합니다. 이는 프로젝트의 일관성을 유지하고, 빌드 과정을 간소화하는 데 도움이 됩니다. Gradle과 Maven의 차이점. 빌드 스크립트 구문 : Gradle은 Groovy나 Kotlin으로 작성된 빌드 스크립트를 사용하는 반면, Maven은 XML 기반의 pom.xml 파일을 사용합니다. Gradle의 DSL은 Maven의 XML보다 간결하고, 읽기 쉽습니다. 성능 : Gradle은 증분 빌드와 빌드 캐시 기능을 통해 Maven보다 빌드 시간을 단축시킬 수 있습니다. Maven은 Gradle에 비해 이러한 최적화 기능이 부족합니다. 유연성 : Gradle은 빌드 스크립트에 로직을 추가하여 빌드 프로세스를 매우 세밀하게 제어할 수 있습니다. Maven은 더 엄격한 라이프사이클과 구조를 따르며, 커스터마이징이 제한적입니다. 플러그인 생태계 : Maven은 오랜 기간 동안 사용되어 왔기 때문에 방대한 양의 플러그인이 있지만, Gradle도 활발히 성장하고 있는 플러그인 생태계를 갖추고 있습니다. 프로젝트 구조 : Maven은 규약을 중시하는 구조로, 프로젝트의 디렉토리 구조가 일정합니다. Gradle은 더 많은 구성 가능성을 제공하지만, 이는 동시에 프로젝트 설정이 복잡해질 수 있음을 의미합니다. 결론적으로, Gradler과 Maven은 각각의 장단점을 가지고 있으며, 프로젝트의 요구사항과 개발 팀의 선호도에 따라 적합한 도구를 선택하는 것이 중요합니다.
Archive
· 2024-02-21
🍃[Spring] API
API @ResponseBody 문자 반환 @Controller public class HelloController { @GetMapping("hello-string") @ResponseBody public String helloString(@RequestParam("name") String name) { return "hello " + name; } } @ResponseBody를 사용하면 뷰 리졸버('viewResolver')를 사용하지 않습니다 대신 HTTP의 BODY에 문자 내용을 직접 반환합니다(HTML BODY TAG를 말하는 것이 아닙니다.) 실행 http://localhost:8080/hello-string?name=spring @ResponseBody 객체 반환 @Controller public class HelloController { @GetMapping("hello-api") @ResponseBody public Hello helloApi(@RequestParam("name") String name) { Hello hello = new Hello(); hello.setName(name); return hello; } static class Hello { private String name; public String getName() { return name; } public void setName(String name) { this.name = name; } } } @ResponseBody를 사용하요, 객체를 반환하면 객체가 JSON으로 변환됩니다. 실행 http://localhost:8080/hello-api?name=spring @ResponseBody 사용 원리 웹 브라우저에서 localhost:8080/hello-api 로 접속을 시도합니다. 톰켓 내장 서버에서 “hello-api 가 왔어” 하고 스프링에 던집니다. 스프링은 “hello-api 가 있네?! 어? 근데 @RespinseBody 어노테이션이 붙어있다!!” 하고 인식합니다. 이런 어노테이션이 붙어있지 않았다면 viewResolver에게 던집니다. -> “나에게 맞는 템플릿을 찾아 돌려줘” @ResponsBody가 있다면 HTTP 응답에 그대로 넘겨야겠다 하고 동작합니다. 여기서 문자가 오면 바로 문자를 돌려줍니다. 하지만 객체가 오면 기본 디폴트인 JSON 방식으로 데이터를 만들어서 HTTP 응답에 반환합니다. -> 기본 정책 @ResponseBody return: hello(name: spring)은 객체를 넘겨줍니다. 그러면 “HttpMessageConverter“ 가 동작합니다. 만약 반환하는 아이가 단순 문자일 경우 “StringConverter“ 가 동작합니다. 그게 아니고 반환하는 아이가 객체일 경우 “JsonConverter“ 가 동작합니다. 결국 JSON 형식으로 변환한 것을 요청한 웹 브라우저에게 보내줍니다. 정리 @ResponseBody를 사용 HTTP의 BODY에 문자 내용을 직접 반환 viewResolver 대신에 httpMessageConverter가 동작 기본 문자처리: StringHttpMessageConverter 기본 객체처리: MappingJackson2HttpMessageConverter byte 처리 등등 기타 여러 HttpMessageConverter가 기본으로 등록되어 있음 참고: 클라이언트 HTTP Accept 헤더와 서버의 컨트롤러 반환 타입 정보 들을 조합해서 HttpMessageConverter가 선택됩니다.
Archive
· 2024-02-18
🍃[Spring] 정적 컨텐츠
정적 컨텐츠. 웹을 개발한다는 것은 크게 3가지 방법으로 나뉩니다. 정적 컨텐츠: 서버에서의 별다른 작업 없이 파일을 웹 브라우저에 그대로 내려주는 것 입니다. MVC와 템플릿 엔진: JSP, PHP 등 활용하여 HTML을 그냥 주는 것이 아니라 서버에서 프로그래밍을 해서 HTML을 동적으로 바꿔서 내려주는 것을 템플릿 엔진이라고 말하며, 그것을 하기 위하여 Model-View(템플릿 엔진 화면)-Controller 이 세가지를 MVC라고 합니다. API: JSON이라는 데이터구조 포맷으로 클라이언트에게 데이터를 전달하는 것이 보통 API 방식이라고 합니다. “스프링 부트는 자동으로 정적 컨텐츠 기능을 제공합니다.” <!DOCTYPE html> <html lang="en"> <head> <meta http-equiv="Content-Type" conten="text/html"; charset="UTF-8" /> <title>Static Content</title> </head> <body> 정적 컨텐츠 입니다. </body> </html> Spring Boot Docs에 다음과 같이 명시되어 있습니다. “기본적으로 Spring Boot는 \static 이라는 디렉터리에서 정적 콘텐츠를 제공합니다.” Spring Boot Docs - Static Content 참고해주세요. “위 그림은 큰 개념을 잡기 위하여 이해하기 쉽게 그린 그림입니다.” Spring MVC를 본격적으로 학습하면서 깊이있게 들어가게 되면 이 내부에 여러가지가 많이 나오게 됩니다. 지금 이 포스팅의 목적 자체는 “디테일” 보다는 “크게 어떻게 돌아가는지를 이해하는데 목적이 있습니다.” 즉, ‘큰 그림을 보는 것’이라고 이해하면 됩니다. 먼저 “localhost:8080/hello-static.html”을 접속했습니다. 제일 처음에 내장 톰켓 서버가 요청을 받습니다. 그러면 내장 톰켓 서버가 “hello-static.html이 왔데요~”하고 “Spring”에게 넘깁니다. 이때, Spring은 Controller에서 hello-static이 있는지 찾아봅니다. “즉, Controller가 먼저 우선순위를 가진다는 뜻 입니다.” 컨트롤러 내부를 보니 “hello-static” 관련 컨트롤러가 없음을 확인할 수 있습니다. 따라서 이후에 스프링 부트는 “resources: static/hello-static.html”을 찾습니다. 그래서 “오 있다!!” 하고 찾으면 바로 “hello-static.html”을 반환해주는 것 입니다.
Archive
· 2024-02-17
🍃[Spring] MVC와 템플릿 엔진
MVC와 템플릿 엔진 MVC: Model, View, Controller Controller package com.devkobe.hellospring.controller; import org.springframework.stereotype.Controller; import org.springframework.ui.Model; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestParam; @Controller public class HelloController { @GetMapping("hello-mvc") public String helloMvc(@RequestParam("name") String name, Model model) { model.addAttribute("name", name); return "hello-template"; } } View <html xmlns:th="http://www.thymeleaf.org"> <body> <p th:text="'hello ' + ${name}">hello! empty</p> </body> </html> 실행 http://localhost:8080/hello-mvc?name=spring MVC, 템플릿 엔진 이미지. 웹 브라우저에서 localhost:8080/hello-mvc를 넘깁니다. 스프링 부트를 띄울 때 함깨 띄우는 “내장 톰켓 서버를 localhost:8080/hello-mvc 가 거칩니다”. 내장 톰켓 서버가 ‘localhost:8080/hello-mvc가 왔어~’ 하고는 스프링에게 던집니다. 그러면 스프링은 ‘아! localhost:8080/hello-mvc가 helloController 내부 메서드에 매핑이 되어있네?!’하고는 “그 메서드를 호출해줍니다.” 호출한 메서드가 리턴시 이름을 “hello-temple”이라고 하고, “model에 키는 name이고, 값은 spring으로 넣은것”을 스프링에게 넘겨줍니다. 그러면 스프링이 “viewResolver” (화면과 관련된 해결자 - 뷰를 찾아주고 템플릿 엔진을 연결 시켜주는 것입니다.)가 동작합니다. viewResolver가 “templates” 의 “hello-template” 이라는 “리턴의 String name과 똑같은 아이를 찾아서 Thymeleaf 템플릿 엔진에게 처리해달라고 넘깁니다.” 그러면 “템플릿 엔진이 랜더링“을 하여 “변환을 한 HTML” 을 “웹 브라우저에 반환합니다.” 정적일 때는 “변환을 하지 않았습니다.” 즉, 그대로 반환을 해줬습니다. 이런 “템플릿 엔진에서는 변환을해서 웹 브라우저에 넘겨줍니다.”
Archive
· 2024-02-17
🍃[Spring Boot] 스프링?
Intro. 스프링 프레임워크(Spring Framework) 는 자바(Java) 가반의 애플리케이션 프레임워크로 엔터프라이즈급 애플리케이션을 개발하기 위한 다양한 기능을 제공합니다. 스프링은 목적에 따라 다양한 프로젝트를 제공하는데, 그중 하나가 스프링 부트(Spring Boot) 입니다. 이번 포스팅에서는 먼저 스프링 부트의 기반인 스프링 프레임워크를 알아보고, 스프링이 제공하는 다양한 프로젝트 중 하나인 스프링 부트의 특징을 설명하겠습니다. 스프링 프레임워크. 스프링 프레임워크(이후 스프링) 는 자바에서 가장 많이 사용하는 프레임워크입니다. 스프링은 자바 언어를 이용해 엔터프라이즈급 개발을 편리하게 만들어주는 ‘오픈소스 경량급 애플리케이션 프레임워크’로 불리고 있습니다. 쉽게 말해서 자바로 애플리케이션을 개발하는 데 필요한 기능을 제공하고 쉽게 사용하도록 돕는 도구입니다. TIP: ‘엔터프라이즈급 개발?’ ‘엔터프라이즈급 개발’은 기업 환경을 대상으로 하는 개발을 뜻합니다. 네이버나 카카오톡 같은 대규모 데이터를 처리하는 환경을 엔터프라이즈 환경이라고 부릅니다. 스프링은 이 환경에 알맞게 설계되어 있어 개발자는 애플리케이션을 개발할 때 많은 요소를 프레임워크에 위임하고 비즈니스 로직을 구현하는 데 집중할 수 있습니다. 스프링의 핵심 가치는 “애플리케이션 개발에 필요한 기반을 제공해서 개발자가 비즈니스 로직 구현에만 집중할 수 있게끔 하는 것” 입니다. 제어 역적(IoC) 일반적인 자바 개발의 경우 객체를 사용하기 위해 아래의 예제 코드와 같은 코드를 사용합니다. @RestController public class NoDIController { private MyService service = new MyServiceImpl(); @GetMapping("/no-di/hello") public String getHello() { return service.getHello(); } } 즉, 사용하려는 객체를 선언하고 해당 객체의 의존성을 생성한 후 객체에서 제공하는 기능을 사용합니다. 객체를 생성하고 사용하는 일련의 작업을 개발자가 직접 제어하는 구조입니다. 하지만 제어 역전(IoC: Inversion of Controller) 을 특징으로 하는 스프링은 기존 자바 개발 방식과 다르게 동작합니다. IoC를 적용한 환경에서는 사용할 객체를 직접 생성하지 않고 객체의 생명주기 관리를 외부에 위임합니다. 여기서 ‘외부’ 는 스프링 컨테이너(Spring Container) 또는 IoC 컨테이너(IoC Container) 를 의미합니다. “객체의 관리를 컨테이너에 맡겨 제어권이 넘어간 것”을 제어 역전이라고 부르며, 제어 역전을 통해 의존성 주입(DI: Dependency Injection), 관점 지향 프로그래밍(AOP: Aspect-Oriented Programming) 등이 가능해집니다. 스프링 을 사용하면 객체의 제어권을 컨테이너로 넘기기 때문에 “개발자는 비즈니스 로직을 작성하는 데 더 집중” 할 수 있습니다. 의존성 주입(DI) 의존성 주입(DI: Dependency Injection)이란 “제어 역전의 방법 중 하나”로, 사용할 객체를 직접 생성하지 않고 외부 컨테이너가 생성한 객체를 주입받아 사용하는 방식을 의미합니다. 스프링에서 의존성을 주입받는 방법은 3가지가 있습니다. 생성자를 통한 의존성 주입 필드 객체 선언을 통한 의존성 주입 setter 메서드를 통한 의존성 주입 스프링에서는 @Autowired라는 어노테이션(annotation)을 통해 의존성을 주입할 수 있습니다. 스프링 4.3 이후 버전은 생성자를 통해 의존성을 주입할 때 @Autowired 어노테이션을 생략할 수도 있습니다. 하지만 스프링을 처음 다룰 때는 가독성을 위해 어노테이션을 명시하기를 권장합니다. 스프링에서 의존성을 주입받는 각 방법에 대한 예시 코드는 아래와 같습니다. // 생성자를 통한 의존성 주입 @RestController public class DIController { // <-- 의존성을 주입 받는 주요부분 MyService myService; @Autowired public DIController(MyService myService) { this.myService = myServicel } // --> @GetMapping("di/hello") public String getHello() { return myService.getHello(); } } // 필드 객체 선언을 통한 의존성 주입 @RestController public class FieldInjectionController { // <-- 의존성을 주입 받는 주요부분 @Autowired private MyService myService; // --> } // setter 메서드를 통한 의존성 주입 @RestController public class SetterInjectionController { // <-- 의존성을 주입 받는 주요부분 MyService myService; @Autowired public void setMyService(MyService myService) { this.myService = myService; } // --> } 스프링 공식 문서에서 권장하는 의존성 주입 방법은 “생성자를 통해 의존성을 주입받는 방식” 입니다. 다른 방식과는 다르게 생성자를 통해 의존성을 주입받는 방식은 “레퍼런스 객체 없이는 객체를 초기화할 수 없게 설계할 수 있기 때문입니다.” 관점 지향 프로그래밍(AOP) 관점 지향 프로그래밍(이후 AOP: Aspect-Oriented Programming) 은 스프링의 아주 중요한 특징입니다. AOP는 OOP를 더욱 잘 사용하도록 돕는 개념으로 보는 것이 좋습니다. 스터디 가이드 OOP를 요약하자면 각 기능을 재사용 가능한 개별 객체로 구성해 프로그래밍하는 것을 뜻합니다. 다음과 같은 OOP의 핵심키워드를 이해한다면 더 나은 객체지행 프로그래밍이 가능합니다. 추상화(abstraction) 캡슐화(encapsulation) 상속(inheritance) 다형성(polymorphism) “AOP는 관점을 기준으로 묶어 개발하는 방식을 의미합니다.” 여기서 “관점(aspect)” 이란 “어떤 기능을 구현할 때 그 기능을 ‘핵심 기능’과 ‘부가 기능’으로 구분해 각각을 하나의 관점으로 보는 것을 의미” 합니다. “핵심기능” 비즈니스로직을 구현하는 과정에서 비즈니스 로직이 처리하려는 목적 기능을 말합니다. 예를 들면, 클라이언트로부터 상품 정보 등록 요청을 받아 데이터베이스에 저장하고, 그 상품 정보를 조회하는 비즈니스 로직을 구현한다면 (1) 상품 정보를 데이터베이스에 저장하고, (2) 저장된 상품 정보 데이터를 보여주는 코드가 핵심 기능입니다. 그런데 실제 애플리케이션을 개발할 때는 핵심 기능에 부가 기능을 추가할 상황이 생깁니다. “핵심 기능인 비즈니스 로직 사이에 로깅 처리를 하거나 트랜잭션을 처리하는 코드를 예로 들 수 있습니다.” 일반적인 OOP 형식으로 비즈니스 로직을 작성하면 아래 그림과 같이 비즈니스 동작 흐름이 발생합니다. OOP 방식의 애플리케이션 로직에서는 위 그림과 같이 객채마다 핵심 기능을 수행하기 위한 “로직” 과 함께 부가 기능인 “로깅”, “트랜잭션” 등의 코드를 작성합니다. 위 그림의 상품정보 등록 기능과 상품정보 조회 기능은 엄연히 다른 기능으로, 각자 로직이 구현돼 있습니다. 하지만 유지보수 목적이나 데이터베이스 접근을 위해 작성된 “로깅” 과 “트랜잭션” 영역은 상품정보를 등록할 때나 상품정보를 조회할 때 동일한 기능을 수행할 확률이 높습니다. 즉, 핵심 기능을 구현한 두 로직에 동일한 코드가 포함된다는 것을 의미합니다. AOP의 관점에서는 부가 기능은 핵심 기능이 어떤 기능인지에 구관하게 로직이 수행되기 전 또는 후에 수행되기만 하면 됩니다. 그래서 아래 그림과 같은 구성으로 만들 수 있습니다. 이처럼 여러 비즈니스 로직에서 반복되는 부가 기능을 하나의 “공통 로직으로 처리하도록 모듈화해 삽입하는 방식” 을 “AOP” 라고 합니다. 이러한 AOP를 구현하는 방법은 크게 세 가지가 있습니다. 컴파일 과정에 삽입하는 방식 바이트코드를 메모리에 로드하는 과정에 삽입하는 방식 프락시 패턴을 이용한 방식 이 가운데 스프링은 디자인 패턴 중 하나인 “프락시 패턴” 을 통해 “AOP” 기능을 제공하고 있습니다. 스프링 AOP의 목적은 OOP와 마찬가지로 모듈화해서 재사용 가능한 구성을 만드는 것이고, 모듈화된 객체를 편하게 적용할 수 있게 함으로써 개발자가 비즈니스 로직을 구현하는 데만 집중할 수 있게 도와주는 것입니다. 스프링 프레임워크의 다양한 모듈 스프링 프레임워크는 기능별로 구분된 약 20여 개의 모듈로 구성돼 있습니다. 아래 그림은 스프링 공식 문서에서 제공하는 다이어그램입니다. 스프링 프레임워크 공식 문서에서는 스프링 버전별로 다른 다이어그램을 제시하고 있지만 큰 틀은 유사합니다. 그리고 스프링 프레임워크를 사용한다고 해서 모든 모듈을 사용할 필요는 없습니다. 애플리케이션 개발에 필요한 모듈만 선택해서 사용하게끔 설계돼 있으며, 이를 “경량 컨테이너 설계”라고 부릅니다.
Archive
· 2024-02-12
🍃[Spring] 라이브러리 살펴보기
🍃[Spring] 라이브러리 살펴보기. Gradle은 의존관계가 있는 라이브러리를 함께 다운로드 합니다. 스프링 부트 라이브러리 spring-boot-start-web spring-boot-start-tomcat: 톰캣(웹서버) spring-webmvc: 스프링 웹 MVC spring-boot-starter-thymeleaf: 타임리프 템플릿 엔진(View) spring-boot-starter(공통): 스프링 부트 + 스프링 코어 + 로깅 spring-boot spring-core spring-boot-starter-logging logback, slf4j 테스트 라이브러리 spring-boot-starter-test junit: 테스트 프레임워크 mockito: 목 라이브러리 assertj: 테스트 코드를 좀 더 편하게 작성하게 도와주는 라이브러리 spring-test: 스프링 통합 테스트 지원
Archive
· 2024-02-09
<
>
Touch background to close
devkobe24.com
