본문 바로가기
관리자

Programming-[Backend]/Spring

(76)
[스프링 기초] 9. 빈 조회하기 1. 빈 조회하기 우리가 원하는 프로그램을 위해서 이제 컨테이너에 등록된 빈들을 조회해야 한다. 즉, 구성영역에 있는 Service와 Repository 등으로 미리 맺어진 관계를 이용해서 필요한 객체들을 불러와야 한다. 2. 빈 조회해보기 빈을 조회하는 메서드는 스프링에서 미리 정해둔 여러가지 메서드를 사용한다. 코드를 보면 간단히 이해할 수 있다. 실무에서는 이런 메서드를 이용해서 빈을 조회하지도 않고, 만약 필요하다고해도 대략적인 이름만 기억하더라도 IDE가 메서드 이름의 목록을 호출해주기 때문에, 굳이 일일이 외울 필요는 없다. 그냥 테스트 코드를 통해 빈들을 조회해보는 실습만 해보면 된다. 대략 아래와 같은 코드로 테스트 해보면 된다. 코드에서 사용되는 빈 메서드 종류를 정리하면 다음과 같다. ..
[스프링 기초] 8. 스프링 컨테이너 이 때까지는 스프링을 사용하지 않고 자바 코드로만 객체지향적 설계를 공부했다. 이제는 스프링 코드로 전환해본다. 1. 스프링 컨테이너 앞에서 공부했듯이, 구성 정보를 관리하는 객체인 AppConfig.class를 DI 컨테이너 등으로 부른다고 했다. 이 DI 컨테이너를 스프링 기술을 도입한 스프링 컨테이너로 만들어보자. @Configuration 어노테이션 클래스 위에 @Configuration 어노테이션을 붙여주었다. 이것은 해당 클래스가 설정(구성) 정보를 관리하는 클래스임을 나타낸다. org.springframework.context.annotation을 import 해야하는 것에 유의하자. @Bean 어노테이션 각 메서드 위에 붙여줌으로써 해당 메서드의 이름을 갖는 '빈' 들을 컨테이너에 등록하게..
[스프링 기초] 7. IoC, DI, 컨테이너 1. IoC(Inversion of Control) : 제어의 역전 이전 글에서 사용영역과 구성 영역을 구분함으로써 객체 지향 설계 원칙을 지킬 수 있었다. 구성 정보를 설정하는 AppConfig 클래스를 만들어서 객체를 생성하고, 할당하였다. 이전글 : 6. 사용영역과 구성영역 나누기로 SRP, OCP, DIP 원칙 실현하기 IoC는 용어의 이름에서 알 수 있듯, 구성 정보를 내가(실행 코드가 있는 객체가) 직접 설정하는 것이 아니라, 외부(라이브러리, 프레임워크 등)에서 이런 과정을 대신해주는 것을 의미한다. -> AppConfig.class 파일에서 구성 정보를 설정해주는 것도 IoC라고 할 수 있다. 2. DI(Dependency Injection) DI는 직역하면 '의존 관계 주입' 이지만, 좀..
[스프링 기초] 6. 사용영역과 구성영역 나누기로 SRP, OCP, DIP 원칙 실현하기 1. 변경 코드 적용 : RateCaringPolicy 동물원의 정책이 바뀌어서, FixedCaringPolicy에서 RateCaringPolicy로 변경됬다. 다행히도 다형성을 지켜가면서 인터페이스로 역할을 만들어놨기 때문에, 기존 인터페이스를 상속받는 새로운 클래스를 만들기가 수월하다. RateCaringPolicy CaringPolicy 역할(interface)을 그대로 상속받기 때문에 작성해놓았던 totalExpense 메서드를 그대로 활용할 수 있다. 2. SRP, OCP, DIP 위반 그런데, 바뀐 RateCaringPolicy를 적용하기 위해서 클라이언트와 소통하는 Service 코드를 살펴보면 OCP, DIP 그리고 SRP가 위반되어 있는 것을 알 수 있다. 아래 코드를 보면서 뭐가 잘못된..
[스프링 기초] 5. 예제만들기2 : SRP 원칙 및 객체 주입, 의존에 대한 이해 1. 예제 확장 위 그림과 같이 예제를 확장해보자. Plan(Creature, CaringPrice, Policy) 관리 계획에서는 Plan이라는 객체가 있고, Plan은 생물(creature)의 종류, 생물 종류에 따른 Caring Price, 관리 정책 Policy에 의해 제어된다. Service, 로직을 구현하는 위치 클라이언트로부터 받은 파라미터 값을 검증(validation)하거나, 계산하는 등 input값을 바탕으로 적절한 output을 만들어 내는 곳이다. Creature, 관리 대상인 생물들 생물들은 각기 무게(weight)가 있고, 무게에 비례하게 관리 비용(expense)이 든다고 가정한다. 또한 동물이든 식물이든 멸종위기 종의 기준인 Grade가 있어서, 일반 종은 Normal, 멸종..
[스프링 기초] 4. 예제 만들기 1. creature 패키지 1-1. Grade Enum NORMAL과 ENDANGERED 속성을 만든다. 1-2. Creature 클래스 Creature 클래스를 만든다. 이 클래스는 필드로 id, name, grade를 갖는다. 생성자와 getter, setter를 만들어준다. 2. Repository 생물들에 대한 정보를 저장할 수 있는 Repository를 만든다. 원래는 Database에 Table을 만들어 정보를 저장하는데, 해당 강의에서는 다루지 않는 범위이므로 여기서는 Map 객체로 메모리 저장소를 만든다. 인터페이스 정의 interface 형태로 creatureRepository를 만든다. 생물들의 정보를 저장할 수 있는 save, 조회할 수 있는 findById 메소드를 만든다. 위에서..
[스프링 기초] 3. 프로젝트의 구조 및 생성 1. 예시 프로젝트 구조 김영한님의 강의를 그대로 따라하는 것보단, 조금 내용을 바꿔가며 학습해야 생각을 하면서 학습할 수 있을 것 같다. 강의에서는 회원들의 정보를 다루는 도메인을 예시로 든다. 이와 유사하게 동물원을 만든다고 생각하고, 동물원에 포함된 생물들(Creature)을 관리하는 도메인을 만들어보자. 구조는 아래 그림과 같이 강의 내용과 동일하다. Service와 Repository는 기본적으로 Interface 형태로 만든다. 여기서 핵심은, 객체를 interface로 만들어서 다형성을 활용하여 코드의 변경이 용이하게 한다는 점이다. CreatureRepository를 상속받는 구현체가 CreatureRepositoryAnimals가 되든, CreatureRepositoryPlants가 되든..
[TIL] BeanUtils.copyProperties, 엔티티 객체 복사하기 1. 용도 특정 객체의 필드값들을 복사한 새로운 엔티티를 반환해준다. 이런 기능을 사용하지 않으면 같은 객체를 만들기 위해서 모든 필드값을 일일이 set해줘야하는데, 이런 불편함을 해결해준다. 2. 사용법 파라미터로 기존 엔티티(originEntity), 복사할 엔티티(targetEntity), 복사안할 필드값("id")를 차례대로 작성해준다. 추가 참조1에 따르면, 기존 엔티티(source)에는 Getter가 필요하고, 복사할 엔티티(target)에는 Setter가 있어야한다고 한다. 해당 메서드의 스펙이 그렇다. 참조 참조1) https://zzang9ha.tistory.com/304