들어가며 > 왜 간단하게 System.out.print()으로 로그를 출력하지 않을까? 유연성을 위해서 선택 가능한 우선순위(`DEBUG`, `INFO`...) 수준 이상의 출력 메시지를 표시할 수 있음 모든 모듈이나 특정 모듈/클래스에 대해서만 메시지를 출력할 수 있음 이러한 메시지들의 형식을 어떻게 지정할지 제어할 수 있음 어디로 보낼지 결정할 수 있음 Logging Framework 네이티브인 `java.util.logging`은 잘 사용하지 않음 `Log4J` 몇 년간 사실상 표준(de facto)이었음 `Logback` Log4J의 개발자가 만든 후속작으로 현재 많은 프로젝트에서 사용됨 `SLF4J` (Simple Logging Facade for Java) Facade 패턴을 사용하는 인터페이스로 Log4J, Logback 등 실제 로깅 프레임워크의 공통된 인터페이스 역할 Facade Pattern (퍼사드 패턴) !Facade Pattern 클라이언트는 퍼사드(Facade)에 요청을 보내는 방식으로 서브시스템과 소통하며, 퍼사드는 해당 요청을 적절한 서브시스템 객체로 전달함 실제 작업은 서브시스템 객체들이 수행하지만, 퍼사드는 자신의 인터페이스를 서브시스템 인터페이스로 변환하기 위한 작업을 수행해야 할 수 있음 클라이언트가 서브 시스템에 직접 접근하지 않아도 됨 ※ 캡슐화(정보 은닉)와 목적이 다름 SLF4J (Simple Logging Facade for Java) !SLF4J `java.util.logging`, `Log4j`, `Logback` 등 다양한 로깅 프레임워크에 대해 간단한 퍼사드(혹은 추상화 레이어) 역할 slf4japi2.0.12.jar 하나를 의존성에 추가해야 함 클래스패스에 로깅 프레임워크와 연결(binding)되는 구현체가 없다면, SLF4J는 아무 동작도 하지 않는(nooperation) 상태로 동작 Logback > log4j의 후속작으로 더 빠르고 가벼움 !Logback logbackclassic 모듈을 사용하려면, 클래스패스에 다음 JAR 파일들이 반드시 포함되어야 한다. slf4japi.jar logbackcore.jar logbackclassic.jar ※ 스프링부트에서 `springbootstarterlogging`은 로킹 프레임 워크를 포함함 위 예제는 logback 관련 클래스는 전혀 사용하지 않았다는 점에 주목 오직 SLF4J의 클래스만 import 하면 됨 따라서, 코드는 SLF4J API만 사용하고, Logback이 존재한다는 사실을 몰라도 됨 Logger Logger는 이름을 가진 엔티티(객체)로 이름을 대소문자를 구분하며 계층적인 이름 규칙을 따름 `kr.ac.hansung` 이름의 Logger는 `kr.ac.hansung.cse` Logger의 부모 root logger는 계층 구조의 최상위 Logging Level > Logger에 레벨을 지정할 수 있다 로그 레벨은 `TRACE` → `DEBUG` → `INFO` → `WARN` → `ERROR` 순으로 중요도(심각도)가 점점 높아짐 명시적으로 레벨이 지정되어 있지 않다면 가장 가까운 상위 로거의 레벨을 상속 받음 root logger는 항상 레벨이 지정되어 있으며, 기본값은 `INFO`임 예시 Logger name Assigned level Effective level root `DEBUG` `DEBUG` X `INFO` `INFO` X.Y `none` `INFO` X.Y.Z `ERROR` `ERROR` Printing method 어떤 출력 메서드를 사용하는지에 따라 로그 요청의 레벨이 결정됨 → `logger.warn("hello");`는 `WARN` 레벨의 로그 요청 !Logback 로그 요청의 레벨이 해당 로거의 유효 레벨(effective level)보다 크거나 같으면, 그 로그 요청은 활성화(enabled)되었다고 한다. 그렇지 않으면, 즉 로깅 요청의 레벨이 더 낮으면, 그 로그 요청은 비활성화(disabled)되었다고 한다. 로그 요청 허용 여부 (`YES` = 출력됨, `NO` = 무시됨) Logging Request `p` ↓ \ Logger Effective Level `q` → TRACE DEBUG INFO WARN ERROR OFF TRACE YES NO NO NO NO NO DEBUG YES YES NO NO NO NO INFO YES YES YES NO NO NO WARN YES YES YES YES NO NO ERROR YES YES YES YES YES NO Appenders 로그 요청은 하나 이상의 출력 대상(destination)으로 출력될 수 있음 각 출력 대상은 appender(출력기)로 표현되며, 다음과 같은 종류 가능 → `console`, `files` (plain text, HTML...), `remote socket servers`, `databases` !Appenders > 특정 로거의 활성화된 로그 요청은, 해당 로거에 설정된 모든 appender뿐 아니라 상위 계층의 appender들에게도 전달된다. 즉, appender는 로거 계층에서 누적적으로 상속된다.이를 Appender Additivity이라고 부른다. 예를 들어, root 로거에 `console appender`가 추가되어 있다면 모든 활성 로그는 최소한 콘솔에 출력된다. 여기에 추가로 어떤 로거 L에 `file appender`를 설정하면, 및 그 하위 로거의 로그는 파일과 콘솔에 모두 출력된다. 하지만 이러한 기본 동작은 설정을 통해 변경할 수 있다. 즉, additivity 플래그를 `false`로 설정하면 상위 appender 상속을 막을 수 있다. Logger Name Attached Appenders Additivity Flag Output Targets Comment `root` A1 not applicable A1 Since the root logger stands at the top of the logger hierarchy, the additivity flag does not apply to it. `x` Ax1, Ax2 true A1, Ax1, Ax2 Appenders of "x" and of root. `x.y` none true A1, Ax1, Ax2 Appenders of "x" and of root. `x.y.z` Axyz1 true A1, Ax1, Ax2, Axyz1 Appenders of "x.y.z", "x" and of root. `security` Asec false Asec No appender accumulation since the additivity flag is set to false. Only appender Asec will be used. `security.access` none true Asec Only appenders of "security" because the additivity flag in "security" is set to false. ConsoleAppender 패턴 의미 `%d{pattern}` 로그 발생 시각 `%thread` 스레드 이름 `%5level` 로그 레벨 (5자 너비로 좌측 정렬) `%logger{length}` 로거 이름 (최대 길이 지정 가능) `%msg` 로그 메시지 FileAppender > 로그는 콘솔과 파일(test.dat)에 동시에 출력 RollingFileAppender 롤오버 파일(Rollover files): 로그를 하나의 파일에 기록하다가, 특정 조건이 되면 새로운 출력 파일로 전환하는 방식 이러한 조건은 롤링 정책(rolling policies)으로 지정하며, 가장 많이 사용되는 것은 TimeBasedRollingPolicy로, → 매달, 매주, 매일, 매시간마다 새 로그 파일로 전환됩니다. Logback Configuration classpath에 위치한 `logback.xml` 파일 !Logback Configuration

Entity Relationships > 데이터베이스에는 많은 테이블, 테이블간 여러 관계를 가짐 이것을 JPA/Hibernate로 설계 해야함 관계의 다중성에는 네 가지 유형이 있음 `@OneToOne` `@OneToMany`, `@ManyToOne` `@ManyToMany` 관계의 방향은 다음과 같을 수 있음 양방향(bidirectional) : 주인 쪽(owning side)과 반대 쪽(inverse side)이 존재함 단방향(unidirectional) : 주인 쪽(owning side)만 존재함 주인 쪽(owning side)은 참조를 테이블에 실제로 저장하는 엔터티 즉 외래 키(foreign key)를 가진 테이블 Entity Relation Attributes Cascading 업데이트/삭제 연관된 엔터티에 동일한 작업을 적용함 CascadeType: `ALL`, `PERSIST`, `MERGE`, `REMOVE`, `REFRESH` Cascade Type 설명 적용되는 작업 ALL 모든 작업(저장, 업데이트, 삭제 등)이 자식 엔티티에 전파됨. 부모의 `persist`, `merge`, `remove`, `refresh`, `detach` 작업 모두 자식 엔티티에 전파 (영속성 컨텍스트에서만 적용) PERSIST 부모 엔티티가 영속화(persist)될 때 자식 엔티티도 영속화됨. 부모의 `persist` 작업이 자식 엔티티에 전파됨 (영속성 컨텍스트에서만 적용) MERGE 부모 엔티티가 병합(merge)될 때 자식 엔티티도 병합됨. 부모의 `merge` 작업이 자식 엔티티에 전파됨 (영속성 컨텍스트에서만 적용) REMOVE 부모 엔티티가 삭제(remove)될 때 자식 엔티티도 삭제됨. 부모의 `remove` 작업이 자식 엔티티에 전파됨 (영속성 컨텍스트에서만 적용) REFRESH 부모 엔티티가 새로 고침(refresh)될 때 자식 엔티티도 새로 고침됨. 부모의 `refresh` 작업이 자식 엔티티에 전파됨 (영속성 컨텍스트에서만 적용) DETACH 부모 엔티티가 분리(detach)될 때 자식 엔티티도 분리됨. 부모의 `detach` 작업이 자식 엔티티에 전파됨 (영속성 컨텍스트에서만 적용) ※ 기본적으로는 어떠한 작업도 연쇄되지 않음 연관된 엔터티를 가져오는 전략(Fetching strategy) FetchType: `LAZY`, `EAGER` EAGER는 모든 것을 한 번에 가져옵니다. 성능 문제로 이어질 수 있음 LAZY는 요청 시에만 데이터를 가져옵니다. ※ 즉, 프로퍼티에 접근할 때까지 해당 행(row)을 로드하지 않음 Mapping Default Fetch Type `@OneToOne` FetchType.EAGER `@OneToMany` FetchType.LAZY `@ManyToOne` FetchType.EAGER `@ManyToMany` FetchType.LAZY > Many가 포함되면 FetchType.LAZY가 Default OneToMany Unidirectional 한 강사는 여러 강의를 가질 수 있다. 일대다(OnetoMany) 관계에서는 외래 키(Foreign Key)가 항상 “Many” 쪽에 존재 `@ManyToOne` 애너테이션을 사용하여 JPA/Hibernate에게 어떤 객체가 자식 객체인지 알려줄 수 있습니다. `@OneToMany` 애너테이션을 사용하여 JPA/Hibernate에게 어떤 객체가 부모 객체인지 알려줄 수 있습니다. `@JoinColumn` 애너테이션을 사용하면, 어떤 컬럼을 조인에 사용할지 명시할 수 있으며, 해당 컬럼의 이름도 지정할 수 있습니다. ※ 즉, 부모 테이블(instructor), 자식 테이블(course) 중에서, 자식 테이블이 외래 키를 가짐 OneToMany Bidirectional 객체 간에 양방향(bidirectional) 관계가 있을 때, 두 객체는 서로 접근할 수 있다. 양방향 관계를 사용하려면, 기존의 데이터베이스 스키마를 그대로 유지할 수 있음 ※ 데이터베이스 변경 X, 단지 Java 코드만 업데이트 > 이 연관관계의 주인은 Course 쪽의 instructor 필드 모든 객체를 올바르게 유지하는 방법 부모 객체를 생성 자식 객체들을 생성 자식 객체들에 부모 객체를 설정 부모 객체에 자식 객체들의 모음을 설정 부모 객체를 저장 OneToOne Unidirectional ManyToMany Unidirectional 학생은 많은 수업을 가질 수 있고 수업도 많은 학생을 가질 수 있다. !Many To Many > Join Table을 두고 관계를 유지하는 것이 효율적 조인 테이블 (Join Table) !Many To Many 다대다(ManytoMany) 관계를 위한 좋은 설계는 조인 테이블을 사용하는 것 조인 테이블이라는 용어는 두 테이블의 기본 키(primary key)만 저장하는 세 번째 SQL 테이블을 설명하는 방법 관례상, 이 조인 테이블의 이름은 일반적으로 다대다 관계를 맺는 두 테이블의 이름을 결합한 형태 ex) course_student 이 조인 테이블은 course 테이블과 student 테이블에서 기본 키만 포함 전체 구조 !Architecture

JPA란? > Standard API for ObjecttoRelational Mapping (ORM) 모든 저수준(lowlevel) SQL 처리 개발자들이 객체 모델을 사용하여 프로그래밍에 집중할 수 있도록 도움 !ObjectToRelational Mapping (ORM) 단순 명세 인터페이스 집합을 정의함 사용하기 위해서 구현이 필요함 표준 API를 사용함으로써, 공급자의 구현에 얽매이지 않음 ※ JPA는 구현이 없는 명세나 인터페이스임 ※ Hibernate는 JPA의 구현체임 JDBC vs JPA(Hibernate) vs Spring Data JPA !JPA JDBC: LowLevel Database Access JPA: Java Persistence API를 나타내는 기술적 명세, 관계형 데이터베이스를 위한 인터페이스로 정의됨 Hibernate: JPA의 구현체 Spring Data JPA: JPA를 쉽게 하용하도록 만든 모듈 !JPA Entity Class > 데이터베이스 테이블에 매핑되는 자바 클래스 !Entity Class 최소 조건 @Entity 주석 필수 public 혹은 protected 기본 생성자 필수 (다른 생성자도 가질 수 있음) Java Annotations 1단계: 클래스를 데이터베이스 테이블에 매핑하기 2단계: 필드를 데이터베이스 컬럼에 매핑하기 @Table !Map class to database table 선택사항으로 없으면 클래스 이름으로 자동 설정됨 @Column !Map fields to database columns 선택사항으로 없으면 필드 이름으로 자동 설정됨 @Id, @GeneratedValue Primary Key !Primary Key 각 행을 고유하게 실벽 반드시 고유한 값으로 NULL일 수 없음 ID Generation Strategies 타입 설명 GenerationType.Auto 특정 데이터베이스를 위한 적절한 전략을 선택 GenerationType.IDENTITY 데이터베이스 ID 열을 사용하여 Primary Key 할당 GenerationType.SEQUENCE 데이터베이스 시퀀스로 Primary Key 할당 GenerationType.TABLE 기본 키의 고유성을 보장하기 위해 기본 데이터베이스 테이블을 사용하여 할당 Entity Manager !Entity Manager EntityManagerFactory : EntityManager의 객체 제공 JPA EntityManager (interface) : 특정 애플리케이션에서 데이터베이스를 접근하기 위해 사용 > EntityManager API는 영속적인 엔티티 인스턴스를 생성 및 제거하고, 기본 키로 엔티티를 찾으며, 엔티티를 대상으로 쿼리를 수행하는 데 사용됩니다. Action JPA Methods Hibernate Methods Create/Save new Entity entityManager.persist(...) session.save(...) Retrieve Entity by ID entityManager.find(...) session.get(...)/load(...) Retrieve list of Entities entityManager.createQuery(...) session.createQuery(...) Save or Update Entity entityManager.merge(...) session.saveOrUpdate(...) Delete Entity entityManager.remove(...) session.delete(...) Persistence Contetxt !Persistence Contetxt EntityManager 객체는 Persistence Context와 연관된다. Persistence Context는 Entity 객체들의 집합으로 데이터베이스에서 엔티티를 가져오거나 데이터베이스에 저장할 때 사용되는 1차 캐시 Entity Lifecycle !Entity Lifecycle 상태 Persistence Context에 있음? 설명 New / Transient ❌ 아님 아직 저장되지 않은 순수 객체 Persistent / Managed ✅ 있음 Persistence Context가 관리 중 Detached ❌ 아님 한 번 저장됐지만 지금은 관리되지 않음 Removed ✅ 있음 (삭제 대기 상태) 삭제 예약된 상태. flush/commit 시 실제 삭제 EntityManager API > CRUD (Create, Read, Update, Delete) ※ EntityClass와 Primary Key 전달 > 복잡한 연산은 어떻게 할까? JPA Query Language (JPQL) 객체들을 조회하기 위한 Query Language SQL과 비슷하지만 JPQL은 entity name과 entity fields에 기반함 ※ Class 이름과 Return 타입 전달 ※ 엔티티 이름 필드 이름에 주의가 필요함 ※ Query에 변수 사용 시 parameter를 설정해주어야 함 DAO (Data Access Object) 데이터베이스를 규격화 함 JPA Entity Manager가 필요함 (조회, 저장을 위한 기본 컴포넌트) !Data Access Object JPA Entity Manager JPA Entity Manager는 데이터 소스가 필요함 데이터 소스는 데이터베이스 연결 정보를 정의함 JPA Entity Manager를 Student DAO에 자동 주입하거나 주입할 수 있음 Spring @Transactional 자동으로 JPA 코드에 대한 트랜잭션을 시작하고 종료함 코드를 명시적으로 작성할 필요가 없음 사용자 모르게 처리됨

Web Basics Request Parameter란 사용자가 발행한 HTTP 요청 메시지의 일부분으로 전송됨 두가지 전송 방식이 있음 Query string (GET Method) HTTP entity body (POST Method) !GET !POST Data Binding > 요청 파라미터에서 해당하는 객체로 어떻게 이동할 것인가? Naive solution @RequestParam annotation을 사용하여 requset parameter와 method parameter를 바인딩 할 수 있다. Spring Data Binding 요청 파라미터를 form bean에 바인딩하는 과정으로, form에서 오는 데이터는 자동으로 객체에 바인딩 될 수 있음 > 함수 파라미터에 객체를 선언하기만 하면 됨 다음과 같은 작업들이 발생함 새로운 form bean 인스턴스화됨 form bean은 요청 파라미터로부터 채워짐 form bean은 모델에 추가됨 !Data Binding offer form bean은 모델에 자동적으로 추가됨 form bean은 모델 속성 !Data Binding 뷰에서도 접근, form bean을 랜더링할 수 있다. Data Validation > 유저는 실수를 할 수 있다 그렇기에 에러를 설명하거나 유저가 이를 해결할 수 있도록 하고 싶다. Hibernate Validator 사용자의 에러를 검출하기 위해, 폼 빈에 캡슐화된 폼 데이터를 검증해야함 Bean Validation API (JSR303)는 JavaBean 검증을 위한 API를 정의하는 명세입니다. 폼 빈 속성에 선언적 검증 제약 조건을 주석으로 달 수 있습니다. (`@NotNull`, `@Pattern`, `@Size`) Hibernate Validator는 몇가지 커스텀 annotation을 제공 (`@Email`) Message Interpolation > 위반된 Bean Validation 제약 조건에 대해 오류 메시지를 생성하는 것 !Message Interpolation > 각 속성의 message descriptor를 메시지 속성을 통해 정의할 수 있습니다 Validating Object 검증은 @Valid 어노테이션을 통해 이루어짐 @Valid 어노테이션은 객체가 먼저 검증된 후 모델에 추가되도록 함 핸들러 메서드는 검증 과정의 결과를 나타내는 BindingResult 객체 요청 가능 가능한 검증 오류를 확인하기 위해 BindingResult 객체 검사 가능 Data Buffering > 사용자가 필수 입력 사항을 잊었을 때 처음부터 다시 입력해야하는가? Spring form tag library 해당 내용을 웹 폼에 바인딩해야 함 Spring은 미리 채워진 폼 빈을 처리하기 위해 데이터 바인딩을 지원하는 태그 세트를 제공함 !Spring form tag library 해당 라이브러리 사용을 위해 JSP 페이지 최상단에 아래를 추가해야함 Spring form tag lib HTML `` `` `` `` `` `` `` `` Revised JSP 다음은 앞선 라이브러리를 사용한 코드이다 Revised Controller !initial Web Form !Web Form on Error Error Messages > 사용자에게 데이터가 거부된 이유를 알려주어야 함수 !Error Messages 이를 위해, BindingResult 객체는 자동으로 모델에 삽입되어 뷰로 다시 전송함 Spring MVC는 Spring의 폼 태그 라이브러리의 일환으로 `` 태그 제공. `` 태그는 BindingResult 객체에서 가져온 HTML 오류 메시지를 렌더링합니다. Summary 폼 빈(Form beans)은 여러 역할을 동시에 수행할 수 있는 다재다능한 객체 데이터 바인더(Data binder): 폼 데이터를 Java 객체에 바인딩하는 역할 데이터 검증기(Data validator): 폼 데이터의 유효성을 검사하고 검증하는 역할 데이터 버퍼(Data buffer): 폼 데이터가 임시로 저장되거나 관리되는 역할

MVC Pattern 스프링은 프레임워크는 MVC 아키텍쳐를 제공한다 Model 데이터 캡슐화, POJO로 구성됨 View model 데이터를 랜더링, 대체로 HTML 형식 Controller 사용자 요청 처리, 적절한 모델을 만들고 view 랜더링을 위해 넘겨줌 !MVC 패턴 Dispatcher Servlet 프론트 컨트롤러 역할 모든 요청을 가로채고 핸들러(컨트롤러)로 전달 요청을 처리할 컨트롤러를 호출하기 위해 핸들러 매핑을 참조 Handler Mapping 특정 요청을 처리할 적합한 컨트롤러를 찾는 역할 요청 URL과 컨트롤러 클래스 간의 매핑은 XML 설정, 애노테이션을 통해 수행 Controller 요청을 처리하며 비즈니스 로직 호출 출력은 모델 객체에 첨부되어 뷰로 전달 View Resolver 논리적 이름으로부터 실제 뷰 파일을 찾는 역할 View JSP, HTML ... 같은 실제 뷰 파일을 의미 Required Configuration Maven Configuration POM.xml Web deployment descriptor Web.xml Spring MVC Configuration `rootcontext.xml`, `servletcontext.xml`, `daocontext.xml`, `servicecontext.xml` Maven Configuration > 각종 라이브러리의 의존성 선언 !POM.xml Web deployment descriptor DispatcherServlet Spring 컨테이너(WebApplicationContext) 인스턴스화 다른 DI 컨테이너와 마찬가지로, WebApplicationContext는 일부 구성 메타데이터를 제공받아야 함 !DispatcherServlet ContextLoadListener 공유 Beans가 포함된 Spring Container 인스턴스화 DispatcherServlet에 의해 생성된 Beans은 ContextLoaderListener에 의해 생성된 Beans를 참조할 수 있음 (DispatcherServlet's Beans → ContextLoaderListener's Beans) Spring MVC Configuration `rootcontext.xml` 파일이 Spring 애플리케이션의 루트 컨테이너 설정을 담당하며, 기본적으로 비어 있지만 애플리케이션 시작 시 자동(`ContextLoaderListener`) 으로 로드된다 `servletcontext.xml` `DispatcherServlet에 의해 로딩됨 `` 프레임워크에 패키지 내 파일 스캔을 annotation based로 수행할 것임을 알림 `` 정적 메소드는 GET 요청으로 바로 접근할 수 있도록 매핑 Bean `InternalResourceViewResolver` 물리 JSP 파일들을 논리 이름으로 어떻게 찾을 수 있는지 알려줌 `` Spring Container에게 annotation based 사용시 어떤 패키지가 스캔될지 알려줌 Model 모델은 결과의 일부를 포함하며 객체를 컨트롤로에서 뷰로 전달할 때 사용된다. 이는 명명된 객체의 모음이다. Key(name) Value key1 value1 key2 value2 key3 value3 > 각 행은 named object 혹은 model attributes 로 불림 !Model 모델 구현 방법은 세 가지로 나눌 수 있다. Map java.util.Map Model Spring 에서 제공하는 Model interface 구현하여 사용된다 Model에서는 key 값을 지정해줄 필요가 없음 모델을 채우기 위한 편리한 방법 제공됨 (addAttribute()) key 값을 자동 혹은 수동으로 지정할 수 있음 ModelMap Spring에서 제공되는 객체로 더 편리함을 제공 (chained calls) Controller > @Controller 어노테이션이 붙은 빈(bean) @Controller 어노테이션 컨트롤러 역할을 한다는 것을 나타냄 @RequestMapping 어노테이션 URL ↔︎ 전체 클리스, 특정 핸들러 메소드 매핑 Class level mapping Handler level mapping Example Add attributes to the model Retrieve request parameters as regular parameters > http://localhost:8080/spring/login?username=scott&password=tiger JSTL JSP는 Java Server Pages의 약자로, 동적인 웹 페이지를 생성하는 데 사용되는 기술 prefix “c” can be used for core language prefix “fn” for using JSTL functions

의존성이란? 이러한 경우 PetOwner는 AnimalType에 의존하게 된다. 하지만 이러한 구조에는 문제가 있는데 다음과 같다. PetOwner 객체가 AnimalType 객체 생성을 관리하기 때문에 두 객체 사이의 Tight Coupling이 발생한다. > 따라서 AnimalType 객체의 변경은 PetOwner의 변경을 야기한다 의존성 주입 (Dependency Injection) 앞선 문제점은 DI를 통해 해결할 수 있다. !DI Bean Container는 Bean을 생성하고, 의존성 주입을 수행한다. 의존성 주입도 제어의 역전(IoC)의 한 종류이다. 따라서 코드는 다음과 같이 변화할 수 있다. > 따라서 의존성 주입(DI)는 객체가 자신의 의존성을 직접 처리하는 것이 아니라, 프레임워크에 의해 의존성이 주입되는 디자인 패턴이다. 이 패턴은 프레임워크에 의해 동적으로 주입되기 때문에 여러 객체 간의 결합도를 줄여준다. Spring (IoC) Container 스프링 프레임워크의 코어 컴포넌트로 객체 생성 관리, 객체 의존성 주입의 주요 기능을 갖고 있다. Spring Container의 구성하는 방법 세 가지 xml Java annotation Javabased Configuration Spring Container의 종류 두 가지 BeanFactory ApplicationContext BeanFactory ApplicationContext 매우 간단, 주로 DI를 위함 더 확장, 고급 기능 제공 리소스가 제한된 경우 사용 (모바일...) 아래 특징을 가진 어느곳애서든 사용 1. 엔터프라이즈 인식 기능2. 애플리케이션 이벤트를 리스너에 게시3. 요청 시 빈을 연결하고 폐기 org.springframework.beans.factory.BeanFactory org.springframework.context.ApplicationContext XMLBeanFactory ClassPathXmlApplicationContext 전체 플로우 !Spring Container and DI main 함수에서 ApplicationContext 객체 생성 Spring Container가 Bean 생성 의존성 주입 수행 Advantages of DI 의존성을 낮추어 코드 변경 줄어듦 코드 재사용성 증가 테스트 용이 (mock implements를 주입시키면 되기 때문에) 코드 가독성 증가 Bean이란? 스프링에서 POJO 클래스를 Bean이라고 부름 Configuration metadata를 통해 Spring Container에 의해 생성되고 관리됨 getBean() 메서드로 객체에 접근할 수 있음 Spring Bean Definition Key 역할 class (required) 클래스 네임 구분 id bean을 구분하는 식별자 scope 객체의 범위 (singletone, prototype) constructorarg 객체 생성 시 넘겨줄 매개변수 property 생성 시 setter에 넘겨줄 매개변수 init, destory 함수 Spring Annotation Based Configuration Spring 2.5 이후에 개발되어 유명해짐 XML의 구성은 방대해질 수 있음 Default가 아니기에 설정이 필요 빈 설정에서 XML이 어노테이션을 덮어쓴다 (XML이 우선순위가 더 높음) @Required Setter 메소드에서만 가능 @Autowired ⭐️ xml 방식 Annotation 방식 @Qualifier > @Autowired가 타입 모호성을 가질 때 사용 @Resource @Resource는 xml의 id(name)로 구분 @Autowired는 클래스로 구분 다만 작동 방식은 동일함 결론 POJO는 "Plain Old Java Object"로, 복잡한 구조나 규약 없이 간단한 Java 객체를 의미 빈(Bean)은 Spring에서 관리하는 객체로, Spring 컨테이너가 생성하고 관리 제어의 역전(Inversion of Control)은 객체의 생성과 생명 주기를 Spring 컨테이너가 관리하게 하는 디자인 패턴 의존성 주입(Dependency Injection, DI)은 객체 간의 의존성을 외부에서 주입하여, 객체들이 서로 독립적으로 동작(의존성을 낮춤)할 수 있도록 도와줍니다.

사전지식 웹 시스템 웹에서 서로 다른 호스트의 상호 작용을 위한 소프트웨어 시스템 클라이언트서버 기반 HTTP, 메시지 지향적(xml,json) 플랫폼 중립적, 독립적 프레임워크 소프트웨어 품질에는 기능 품질, 구조 품질이 있다. 프레임워크란 구조 품질을 보장한다. 프레임워크는 반제품으로 애플리케이션 구조 및 코드의 상당 부분을 제공, 개발자는 핵심 로직 개발에 집중 가능하다. 이를 통해 높은 생산성과 코드 품질이 보장된다. 라이브러리 ↔ 프레임워크 중요한 차이점은 제어의 역전 (Inversion of Controll)이다. 라이브러리 프레임워크 차이 제어의 주체: 개발자(호출)클래스의 집합: 코드 재사용 ↑ 제어의 주체 : 프레임워크 (IoC) 프레임워크의 구조에 따라 코드 작성하면 프레임워크에서 호출 스프링이란? > Light weight JavaApplication Framework POJO 기반의 앤터프라이즈 애플리케이션 개발을 쉽고 편하게 함 자바 애플리케이션을 개발하는데 필요한 하부구조 (infrastructure)를 포괄적으로 제공 스프링이 하부 구조를 처리하므로 개발자는 애플리케이션 개발에 집중 스프링의 주요 특징 의존 관계 주입 (Dependency Injection) 관점 중심 프로그래밍 (Aspect Oriented Programming) 이식 가능한 서비스 추상화 (Portable Service Abstraction) DI 객체간의 의존성을 낮추기 위함 객체와 그 의존성을 직접 생성하는 대신, 외부 엔티티(즉, Spring IoC Container)에 의해 객체가 생성 및 구성된다 PersonService는 Person에 의존한다 Spring Container에 의해 생성된 Person 객체는 생성자를 통해 주입된다. AOP 애플리케이션의 핵심 비즈니스 로직과 공통적으로 필요한 부가 기능(예: 로깅, 보안, 트랜잭션 관리 등)을 분리하여 모듈화하는 프로그래밍 패러다임 관심사의 분리: 비즈니스 로직과 부가 기능을 분리하여 각각의 역할을 명확히 함 재사용성 증가, 유지보수 용이 > 비즈니스 로직과 로깅 로직 혼재 > Aspect (LoggingAspect) 로깅 기능을 별도의 클래스로 분리하여 관리 PSA 애플리케이션 코드가 다양한 서비스 제공자와 상호작용할 수 있도록 공통 인터페이스를 제공하는 추상화 계층 공통 인터페이스 제공: PSA 계층은 여러 서비스 제공자(구체적인 서비스 구현체)와 애플리케이션 코드 사이에 일관된 인터페이스를 제공. 애플리케이션 코드는 이 공통 인터페이스를 통해 서비스와 상호작용하므로, 개별 서비스 제공자의 세부 구현에 신경 쓸 필요가 없음 유연한 서비스 전환: PSA를 사용하면 서비스 제공자를 변경할 때 애플리케이션 코드를 수정할 필요 없이 PSA 계층이 제공하는 인터페이스만 준수하면 됩니다. 이로 인해 서로 다른 서비스 제공자 간의 전환이 매우 용이해짐. Spring과의 통합: Spring 환경에서 PSA를 도입하면, 의존성 주입 등과 같은 Spring의 기능을 활용하여 PSA 계층을 관리할 수 있고, 이를 통해 보다 모듈화된 설계와 유지보수가 용이한 코드를 작성 가능. 결론 스프링을 통해 Java Enterprise 시스템 개발이 용이 비즈니스 로직에 집중 가능하여 생산성 증대 재사용 및 유지 보수 용이, 확장성을 가진 코드 설계

들어가며 내가 설계한 기본적인 프로세스는 다음과 같다 `메인 브랜치로 머지` → `Webhook 전달` → `Docker 이미지 빌드` → `Docker Hub에 푸시` → `결과 알림` 본 글에서 Discord 알림을 제외한 모든 프로세스를 다룰 것이다. Jenkins 접속 브라우저에서 ec2 public ip에 8080 포트로 jenkins 서버에 접속한다. > 예시) http://0.0.0.0:8080 > 명령어를 통해 출력된 admin 비밀번호로 로그인이 가능하다. Install suggeseted plugins 설치 로그인 계정을 생성하고 젠킨스 접근 URL을 입력한다 Credentials 생성 GitHub Credentails GitHub Access Token 발급 `Settings` > `Developer Settings` > `Personal access tokens (classic)` > `Generate new token (classic)` repo 관련 권한과 hook 권한을 체크해준다. GitHub Credentails 등록 `jenkins 관리` > `Credentials` > `System` > `Glabal credentials` > `Add Credentials` Kind: Username with password Scope: Global Username: GitHub username Password: GitHub access token ID: Identifier used in pipeline code (e.g., githubcredentials) Docker Credentails Kind: Username with password Scope: Global Username: Docker Email Password: Docker Password ID: Identifier used in pipeline code (e.g., githubcredentials) plugins 다운로드 > GitHub API Plugin > Generic Integration > Generic Webhook Trigger > SSH Agent Plugin > Docker > Docker Pipeline GitHub Webhook 설정 `Settings` > `Webhooks` > `Add webhook` > Payload URL 예시 http://0.0.0.0:8080/githubwebhook/ (jenkins 주소) Pipeline 구축 `new items` > `pipeline` > 사진과 같이 선택하고 GitHub 레포지토리 URL을 넣으면 된다. 결과 확인 > main 브랜치에 머지되면 이미지 빌드를 수행하고 Docker Hub에 업로드 되는 것을 볼 수 있다.

들어가며 캡스톤 디자인 기획, 설걔 단계에서 아키텍쳐 설계 부분을 담당하게 됐다. 지난 2학기에 진행했던 프리캡스톤의 기억을 더듬어보니 EC2 서버에 볼륨이 부족하여 자주 Docker 빌드가 실패하던 악몽이 떠올랐다. 그래서 이번 캡스톤 디자인에서는 Docker 이미지를 운영 서버에서 Build하지 않도록 설계하고자 하였다. !아키텍쳐 내가 설계한 기본적인 프로세스는 다음과 같다 `메인 브랜치로 머지` → `Webhook 전달` → `Docker 이미지 빌드` → `Docker Hub에 푸시` → `결과 알림` EC2 인스턴스 정보 os: Amazon Linux 2023 AMI instance: t2.micro volumn: 30GB Jenkins 설치 Jenkins 저장소 등록 wget 명령어를 사용하여 Jenkins의 yum 저장소 파일을 다운로드합니다. 이를 통해 yum이나 dnf 패키지 관리자가 Jenkins 패키지를 찾을 수 있게 됩니다. Jenkins GPG 키 가져오기 Jenkins 저장소에서 제공하는 GPG 키를 가져와 시스템에 등록합니다. 이 키는 패키지의 무결성과 신뢰성을 확인하기 위해 사용됩니다. Amazon Corretto JDK 17 설치 Jenkins 설치 Jenkins 서비스 부팅 시 자동 시작 설정 Jenkins 서비스 시작 Jenkins 서비스 상태 확인 Git 설치 설치 및 버전 확인 Docker 설치 도커 설치 도커 실행 및 활성화 jenkins 사용자를 도커 그룹에 추가 jenkins 재시작 jenkins 접속 확인 브라우저에서 ec2 public ip에 8080 포트로 jenkins 서버에 접속한다. > 예시) http://0.0.0.0:8080 !접속 성공 🦄

build.gradle 의존성 추가 application.yml 파일 수정 하단에 해당 부분을 추가하여준다. SwaggerConfig 클래스 생성 !접속 성공

패키지 설치 설치 가능한 mariadb 패키지 검색 Mariadb 설치 Mariadb 실행 Mariadb root 비밀번호 설정 로그인 확인 그 외 설정 Docker 이미지 다운로드 DB 생성 및 사용자 설정 SpringBoot 프로젝트 설정 build.gradle 의존성 추가 application.yml, applicationlocal.yml 파일 생성 src/main/resources/application.yml src/main/resources/applicationlocal.yml dockercompose.yml 수정 !🔥 dbeaver 접속 성공

Docker란? Docker는 애플리케이션을 실행할 수 있는 가벼운 가상화 환경인 컨테이너를 생성하는 도구이다. 컨테이너는 시스템의 전체 운영체제를 복제하는 대신, 필요한 부분만 분리하여 애플리케이션을 격리된 환경에서 실행할 수 있게 한다. 이를 통해 개발 환경과 배포 환경의 일관성을 유지하고, 리소스를 효율적으로 사용할 수 있다. Docker는 개별 컨테이너를 만들고 실행하는 데 사용되며, 주로 하나의 애플리케이션 또는 서비스를 컨테이너화할 때 활용된다. 반면에 Docker Compose는 여러 컨테이너를 정의하고 관리할 수 있는 도구로, 복잡한 애플리케이션에서 여러 서비스(예: 웹 서버, 데이터베이스 등)를 한 번에 설정하고 실행할 수 있도록 도와준다. Docker Compose를 사용하면 dockercompose.yml 파일에서 설정을 정의하고, 한 명령어로 여러 컨테이너를 일괄적으로 관리할 수 있다. Docker 설치 방법 yum update install docker service docker grant permission to ec2user Docker service start and enable automatic startup Dockercompose 설치 방법 yum에는 기본적으로 Docker Compose 패키지가 없기 때문에, 직접 바이너리를 다운로드하여 설치해야 한다. Dockercompose 바이너리 파일 다운로드 실행 권한 부여 설치 확인 !설치 성공 ✨

들어가며 교내 팀 프로젝트를 통해 백엔드 개발 다수 존재하지만, 환경 구축이나 배포 경험은 부족하다. 이번 학기에는 "다우기술"의 사내 문제를 해결하는 해커톤 형태의 과목을 수강하게 되었고, 팀원들과 역할을 분담하여 초기 백엔드 환경 구축 및 배포를 맡게 되었다. AWS란? AWS(Amazon Web Services)는 클라우드 컴퓨팅을 통해 다양한 서비스를 제공하는 플랫폼으로, 전 세계적으로 사용되는 안전하고 확장 가능한 인프라를 제공한다. 이를 통해 사용자는 서버 자원을 유연하게 조정하고 관리할 수 있으며, 초기 비용 없이 필요한 만큼만 비용을 지불할 수 있다. 본 글에서는 EC2를 사용하여 진행할 것이다. EC2 인스턴스 생성 및 설정 보안 규칙은 다음과 같이 설정해둔다 !보안 규칙 EC2 Instance Console에 접속 인스턴스 생성 시 발급 받은 pem 키가 있을 것이다. 해당 명령어로 권한을 변경하여 준다. !접속 성공 🤩