[SpringBoot] 6주차 스터디(객체 지향, DI)

1. 절차적 프로그래밍 VS 객체 지향 프로그래밍

● 절차적 프로그래밍 

- Service, Repository 를 따로 두지 않고 Controller 하나로 모든 것을 해결하는 방식이다. 각 API의 처리 내용을 쭉 나열해놓는 코딩 방식을 의미한다.

- 하지만 이런 방식은 문제가 있다! 테이블의 필드명을 바꾸거나 DB의 id와 pw 를 바꾸는 등의 경우 바꿔야 할 코드가 많다. 따라서 실수로 변경되지 않은 코드가 생길 수 있고 유지보수 하기 힘들어진다.

 

● 객체 지향 프로그래밍

- 서버에서의 처리 과정을 Controller, Service, Repository 로 분류하는 방식이다

 

① Controller

- 클라이언트의 요청과 응답을 처리한다. 요청에 대한 처리는 Service에게 전담한다.

② Service

- 비즈니스 로직(서버에서의 사용자의 요구 사항)을 처리한다. DB 정보가 필요할 때는 Repository에게 전담한다.

③ Repository

- DB를 관리하고 DB CRUD 작업을 처리한다.

 

2. DI (의존성 주입)

- DI(의존성 주입)은 하나의 객체에서 다른 객체가 필요할 때, 객체를 직접 생성하지 않고, 이미 생성되어 있는 객체를 가져오는 작업이다.

-  필요한 객체를 요청하면 어디서 어떻게 만들어졌는지 알 필요 없는 객체를 사용자가 사용할 수 있게 된다. 사용할 객체의 생성자가 바뀌더라도 사용자 입장에서는 알 수 없고, 알 필요도 없다. 그냥 용도에 맞게 사용하면 된다.

- 중복 코드, 강한 결합을 해결할 수 있는 방법이다.

 

스프링 프레임워크에서 DI(의존성 주입)을 다음과 같이 사용할 수 있다.

• 빈(Bean): 스프링이 생성해주는 객체
• 스프링 IoC 컨테이너: 빈을 모아둔 공간

@Configuration // 스프링이 실행될 때 @Bean 을 바라보고 필요한 객체를 스프링 IoC 컨테이너에 빈으로 담는다
public class BeanConfiguration {
    @Bean // 스프링 IoC 컨테이너에 객체(빈)를 담는다
    public ProductRepository productRepository() {
        String dbId = "sa";
        String dbPassword = "";
        String dbUrl = "jdbc:h2:mem:springcoredb";
        return new ProductRepository(dbId, dbPassword, dbUrl);
    }

    @Bean
    @Autowired // 스프링 IoC 컨테이너에 있는 빈을 해당 객체에 DI(의존성 주입) 한다
    public ProductService productService(ProductRepository productRepository) {
        return new ProductService(productRepository);
    }
}

 

@Controller, @RestController, @Service, @Repository 와 같은 어노테이션을 붙이면 모두 스프링의 빈으로 등록된다. 다음과 같은 Repository의 경우 @Repository를 붙이지 않아도 자동으로 스프링이 추가해준다!

public interface ProductRepository extends JpaRepository<Product, Long> {}