Spring Core

• 객체를 관리하는 컨테이너 제공
• 순수자바 POJO (복잡했던 EJB들과 다름)

→ 자바의 오픈소스 애플리케이션 프레임 워크중 하나로 스프링의 기본 철학은 특정 기술에 종속 되지 않고 객체를 관리할 수 있는 프레임 웍을 제공 하는 것. 컨테이너로 자바 객체를 관리하면서 DI(의존성 주입)과 제어의 역전(IoC)를 통해 결합도를 낮추게 됩니다.

DI

• 의존성 주입, 컨테이너가 의존관계를 자동으로 주입
• 객체관의 의존관계를 미리 설정해 두면 컨테이너가 의존관계 자동 주입
• 의존관계 설정에는 과거엔 XML, 요즈음엔 @Annotation 사용한다.

IoC

• 프레임워크 vs 라이브러리
• 프레임워크가 정해놓은 인스턴스 라이프 사이클과 흐름속에 필요에 따라 사용자(개발자)의 코드를 호출하게 됩니다.

ORM

• JPA는 인터페이스, 구현체로는 하이버네이트

• 비즈니스 로직에 집중할 수 있고, 객체 중심 개발을 할 수 있게 합니다. 메소드를 호출하는 것 만으로 쿼리를 사용할 수 있기 때문에 생산성이 향상되고, 유지보수 비용을 절감시킵니다.

• 단점으로는 실행 속도가 조금은 느리다는 점과, 복잡한 쿼리 표현이 어렵다는 점이 있습니다.

• 스프링이란?

  • DI란?

    DI(Dependency Injection)는 스프링 프레임워크에서 IoC(Inversion of Control) 원칙을 구현하는 주요 방법입니다. DI는 객체 간의 의존 관계를 애플리케이션 코드가 아닌 외부 컨테이너가 관리하도록 하는 패턴입니다.

    스프링에서 DI는 주로 스프링 컨테이너가 관리하는 빈(Bean) 객체에 의해 구현됩니다. 스프링 컨테이너는 빈의 생성, 초기화, 소멸 등 생명 주기를 관리하며, 각 빈 간의 의존성을 주입하는 역할을 담당합니다.

    스프링에서는 DI를 주로 다음 두 가지 방식으로 구현합니다:

    1. 세터 주입 (Setter Injection): 의존성을 주입 받을 빈에 세터 메서드를 정의하고, 스프링 컨테이너는 이 세터 메서드를 통해 의존성을 주입합니다.
    2. 생성자 주입 (Constructor Injection): 의존성을 주입 받을 빈의 생성자를 통해 의존성을 주입합니다. 이 방식은 빈이 필요로 하는 의존성을 명확하게 표현할 수 있으며, 주입 받은 의존성의 변경을 막을 수 있어 불변성을 보장합니다.

    이러한 DI의 이점은 다음과 같습니다:

    • 낮은 결합도: DI는 클래스 간의 결합도를 낮추고, 모듈 간의 독립성을 증가시킵니다. 이는 각 클래스나 모듈이 서로에게 덜 의존적이기 때문에 발생하는 효과입니다.
    • 코드의 재사용성 및 유지보수성 향상: DI를 통해 클래스는 필요한 의존성만 주입받아 사용하기 때문에, 코드의 재사용성과 유지보수성이 향상됩니다.
    • 테스트 용이성: DI는 테스트를 용이하게 합니다. 테스트 시에는 실제 객체 대신 모의 객체(Mock)를 주입하여 사용할 수 있으므로, 테스트가 보다 쉬워집니다.

    따라서 스프링의 DI는 객체의 생성과 관리, 그리고 객체 간의 의존성을 안정적으로 관리하면서, 코드의 재사용성, 유지보수성, 테스트 용이성 등을 향상시키는 중요한 메커니즘이라고 할 수 있습니다.

  • 디스패처 서블릿이란?

    스프링의 디스패처 서블릿(DispatcherServlet)은 스프링 MVC 프레임워크의 핵심 컴포넌트로, 모든 HTTP 요청을 중앙에서 처리합니다. 스프링 웹 애플리케이션에서 디스패처 서블릿은 '프런트 컨트롤러' 역할을 하며, 클라이언트 요청을 적절한 컨트롤러에게 전달하고, 컨트롤러가 반환한 결과를 클라이언트에게 반환하는 역할을 합니다.

    디스패처 서블릿의 주요 기능은 다음과 같습니다:

    1. 요청 처리: 디스패처 서블릿은 들어오는 모든 HTTP 요청을 받아들이고 처리합니다.
    2. 핸들러 매핑: 디스패처 서블릿은 요청을 처리할 수 있는 적절한 컨트롤러를 찾는 역할을 합니다. 이는 '핸들러 매핑' 과정을 통해 이루어집니다.
    3. 컨트롤러 선택 및 요청 위임: 적절한 컨트롤러가 결정되면, 디스패처 서블릿은 해당 컨트롤러에게 요청 처리를 위임합니다.
    4. 뷰 렌더링: 컨트롤러는 처리 결과를 모델로 반환하고, 이를 사용하여 사용자에게 보여줄 뷰를 선택합니다. 디스패처 서블릿은 이 뷰를 렌더링하고 결과를 클라이언트에게 반환합니다.

    스프링의 디스패처 서블릿은 이러한 과정을 통해 요청 처리와 응답 반환을 중앙에서 관리하고, 애플리케이션의 아키텍처를 깔끔하게 유지하는 데 도움을 줍니다. 이는 스프링 MVC 프레임워크가 재사용성과 유지 보수성을 갖출 수 있도록 하는 핵심 요소 중 하나입니다.

  • 디스패처 서블릿으로 인한 web.xml 역할 축소

  • AOP란?

  • AOP 용어 설명

  • AOP 사용 경험 : 공통 로그 구현

  • 필터와 인터셉트 차이

  • 스프링(Spring)과 스프링 부트(Spring Boot)는 둘 다 자바로 작성된 애플리케이션을 위한 프레임워크지만, 이들 사이에는 몇 가지 중요한 차이점이 있습니다.

    스프링(Spring):

    • 스프링은 엔터프라이즈급 애플리케이션을 개발하기 위한 컴프리헨시브한 프레임워크로, inversion of control (IoC), aspect-oriented programming (AOP), 데이터 접근, 트랜잭션 관리 등과 같은 다양한 기능을 제공합니다.
    • 스프링은 강력한 기능들을 제공하지만, 그에 따라 설정과 종속성 관리가 복잡해질 수 있습니다. 각각의 모듈이 어떻게 작동하고 어떻게 함께 동작하는지를 정확히 이해하고, 이를 바탕으로 애플리케이션을 구성해야 합니다.

    스프링 부트(Spring Boot):

    • 스프링 부트는 스프링의 'opinionated' 버전으로, 스프링 애플리케이션을 빠르게 개발하고 배포할 수 있게 하는 것이 목표입니다.
    • 스프링 부트는 스타터 종속성, 자동 구성, 내장된 서버 등을 통해 개발 프로세스를 간소화하고 빠르게 프로토타입을 개발하거나 마이크로서비스를 배포할 수 있게 도와줍니다.
    • 하지만, 이 'opinionated' 접근 방식은 사용자가 특정 설정이나 기능을 커스터마이징하려고 할 때 제한적일 수 있습니다.

    따라서 스프링과 스프링 부트의 차이점을 간략하게 요약하면, 스프링은 더 큰 유연성과 세밀한 제어를 제공하지만 설정이 복잡하며, 스프링 부트는 빠른 개발과 간편한 설정을 제공하지만 그에 따라 일부 세부적인 제어력이 제한될 수 있다고 할 수 있습니다.

  • 스프링 MVC 구조 흐름

• 스프링과 스프링 부트 차이

• 스프링 어노테이션

  스프링 프레임워크에서는 많은 어노테이션들이 제공되고, 이들은 코드에 메타데이터를 추가하여 해당 코드의 의미와 역할을 더 명확하게 표현하거나, 스프링 컨테이너가 자동으로 특정 작업을 수행하도록 지시하는 역할을 합니다. 아래는 스프링 프레임워크에서 주로 사용되는 몇 가지 어노테이션들에 대한 설명입니다:

  1. @Component: 클래스가 스프링 빈임을 나타내는 기본 어노테이션입니다. 이 어노테이션을 사용하면 스프링 컨테이너가 해당 클래스의 객체를 생성하고 관리하게 됩니다.
  2. @Service, @Repository, @Controller, @RestController: 이들 어노테이션은 @Component의 특수한 형태입니다. 각각 서비스, 리포지토리, 컨트롤러, REST 컨트롤러 역할을 하는 스프링 빈임을 나타냅니다.
  3. @Autowired: 의존성 주입을 위한 어노테이션입니다. 생성자, 필드, 세터 등에서 사용되며, 해당 위치에 정의된 타입의 빈을 스프링 컨테이너에서 찾아 주입합니다.
  4. @Configuration: 클래스가 스프링 설정 정보를 담고 있음을 나타내는 어노테이션입니다. 이 어노테이션을 사용하는 클래스에서는 주로 @Bean 어노테이션을 사용하여 빈을 정의하게 됩니다.
  5. @Bean: 메서드가 생성한 객체를 스프링 빈으로 등록하도록 지시하는 어노테이션입니다. 이 어노테이션은 주로 @Configuration 클래스 내부에서 사용됩니다.
  6. @RequestMapping, @GetMapping, @PostMapping 등: 이들 어노테이션은 컨트롤러의 메서드가 처리할 HTTP 요청의 경로와 방식을 지정합니다.
  7. @PathVariable, @RequestParam, @RequestBody 등: 이들 어노테이션은 HTTP 요청의 일부를 메서드의 파라미터로 매핑합니다. @PathVariable은 URL의 경로 변수, @RequestParam은 쿼리 매개변수, @RequestBody는 요청 본문을 각각 처리합니다.
  8. @Value: 프로퍼티 값 또는 표현식의 결과를 필드나 메서드 파라미터에 주입합니다.

  이 외에도 스프링 프레임워크는 다양한 어노테이션을 제공하며, 이들은 각각 특정 상황에서 코드의 역할과 의미를 명확히 표현하거나, 스프링 컨테이너의 자동 처리를 지시하는 역할을 합니다. 따라서 각 어노테이션의 의미와 사용 방법을 이해하는 것은 스프링 프레임워크를 효과적으로 사용하는 데 중요합니다.

• 스프링 버전별 기능

• MVC 1과 MVC 2의 차이

• ORM

• JPA

• ORM, JPA, Hibernate 장단점

• Mybatis란?

• Mybatis, JPA 차이

• IoC란?

  IoC(Inversion of Control)는 프로그램의 제어 흐름 구조가 뒤바뀌는 것을 의미하는 소프트웨어 디자인 원칙입니다. 전통적인 프로그래밍에서는 메인 프로그램이 프로그램의 흐름을 제어하고, 필요에 따라 메소드를 호출하거나 객체를 생성하는 등의 작업을 합니다. 하지만 IoC를 적용하면 이러한 제어 흐름이 '프레임워크' 또는 '컨테이너'로 이동하고, 개발자가 작성한 코드는 이러한 흐름에 의해 호출되는 구조가 됩니다.

  스프링 프레임워크에서 IoC는 주로 'Dependency Injection'(DI)이라는 형태로 구현됩니다. 스프링 컨테이너는 객체의 생명 주기를 관리하며, 객체 간의 의존성을 자동으로 주입합니다.

  예를 들어, 어떤 클래스가 다른 클래스의 인스턴스를 필요로 할 때, 전통적인 방식에서는 이 클래스 내부에서 필요한 클래스의 인스턴스를 직접 생성합니다. 하지만 IoC와 DI를 사용하면, 이러한 인스턴스 생성과 연결을 스프링 컨테이너가 대신 해주게 됩니다.

  이러한 접근 방식은 다음과 같은 이점을 제공합니다:

  1. 모듈 간의 결합도 감소: 클래스는 직접적으로 의존성을 생성하거나 관리하지 않기 때문에, 클래스 사이의 결합도가 감소합니다.
  2. 코드의 재사용성 향상: 객체의 생성과 관리를 스프링 컨테이너가 담당하므로, 코드의 재사용성이 향상됩니다.
  3. 테스트 용이성: 의존성을 주입 받는 클래스는 인터페이스에 의존하기 때문에, 테스트 시에 실제 구현 대신 모의 객체(Mock)를 주입할 수 있어 테스트가 용이해집니다.

  따라서 스프링 프레임워크에서의 IoC는 개발자가 객체 생성과 관리에 대한 부담을 줄이고, 좀 더 집중적으로 비즈니스 로직에 신경 쓸 수 있도록 돕습니다.

• Spring JDBC

• DAO, DTO 란?