웹 서버(Web Server) ㆍHTTP를 기반으로 동작 ㆍ정적 리소스(HTML, CSS, JS, 이미지, 영상) 제공 웹 애플리케이션 서버(WAS, Web Application Server) ㆍHTTP를 기반으로 동작 ㆍ웹 서버의 기능에 프로그램 코드를 실행하여 로직을 수행 ㆍ정적 리소스 + 동적 리소스 정적 리소스는 웹 서버가 처리하고, 남은 동적 리소스는 WAS에 처리를 위임하여 애플리케이션 로직을 전담한다. 그러면 WAS는 동적 리소스만 전담하여 처리할 수 있고, WAS에 오류 발생시 오류화면을 웹 서버에서 처리해줄 수 있는 장점이 있다. 서블릿(Servlet) 웹 서버에서 동작하는 웹 어플리케이션 컴포넌트(서비스 페이지)로, 웹브라우저의 요청에 따라서 서버가 실행하는 자바 프로그램을 말하는데, ..
원래는 @RequestMapping 어노테이션을 통해서 URL을 컨트롤러의 메서드와 매핑할때 요청 주소와 방식을 설정하였다. @RequestMapping(value="/check", method={RequestMethod.POST}) 이후 스프링이 업데이트되면서 일일히 RequestMapping의 method를 설정해주지 않고 직관적으로 설정하기 위하여 Mapping관련 어노테이션인 @GetMapping, @PostMapping등이 추가되었다. 일반적으로 GET과 POST매핑을 사용할때, 뷰의 form태그의 method에 따라서 요청 방식이, action에 따라서 uri가 결정된다. 이때, form의 요청을 발생시켜주는 페이지의 uri와 form으로 요청이 들어오는 uri가 같다면 action uri는 ..
변경 감지와 병합 영속성 컨텍스트가 더 이상 관리하지 않는 엔티티, 즉 식별자(id)를 기준으로 영속상태가 되어 DB에 저장되었던 적이 있지만 현재는 아닌 객체를 준영속 상태라고 한다. JPA가 관리하고 있는, 영속성 상태 객체의 변경감지는 transaction이 commit될때 작동한다. 하지만 준영속 상태의 엔티티는 JPA가 관리하지 않아서 변경 감지가 일어나지 않는다. 그래서 단순히 java 객체의 상태를 업데이트 하는 것만으로는 갱신이 일어나지 않는다. 이러한 준영속 상태의 엔티티를 변경하기 위해서는 변경 감지(Dirty Checking) 기능을 사용하거나, 병합(merge)를 사용할 수도 있다. 변경 감지 @Transactionalpublic void updateItem(Item item..
Layering 실무에서 다루는 복잡한 프로그램들은 우리가 개념을 배울 때 사용하는 예시 프로그램과 같은 간단한 구조로 이루어져있지 않다. 이러한 복잡한 프로그램을 다루는 가장 일반적인 방법은 layer를 분리하는 것이다. 이렇게 Layering을 하는 목적은 추상화에 그 목적이 있다. JSP와 같이 하나의 파일로 여러가지 역할을 처리하면, 너무 많은 역할을 하게 된다. 비즈니스 로직을 호출하는 부분에 변경이 발생해도, UI를 변경할 일이 있어도 모든 경우에 하나의 파일에 접근하여 코드를 수정해야 하는 것이다. 그래서 적절한 Layering은 추상화를 성공시켜 각기 다른 layer끼리는 서로 변경에 영향을 받지 않게 되고, 이것은 유지보수에 큰 이점을 가져다준다. 개발자들은 다양한 프로젝트를 통해서 최선..
개념 빈 스코프란 스프링 빈이 존재할 수 있는 범위를 이야기한다. 스프링은 다음과 같은 다양한 스코프들을 지원한다. 싱글톤 : 스프링 컨테이너의 시작과 종료까지 유지되는 가장 넓은 범위의 기본 스코프이다. 프로토타입 : 스프링 컨테이너는 프로토타입 빈의 생성과 의존관계 주입까지만 관여하는 짧은 범위의 스코프이다. request : 웹 요청이 들어오고 나갈때까지 유지되는 스코프이다. session : 웹 세션이 생성되고 종료될때까지 유지되는 스코프이다. 싱글톤 (Singleton) @Scope("singleton") 싱글톤 스코프란 앞서 공부했듯이 어플리케이션 전반에 걸쳐 해당 빈의 인스턴스를 오직 하나만 생성해서 사용하는 방법이다. 자바상의 싱글톤 패턴은 여러가지 단점을 가져오기도 하지만 스프링은 그러한..
@Autowired를 이용해서 조회하면, 이것은 getBean메소드를 이용해서 타입 조회하는것과 유사하게 동작한다. 그런데 선택된 빈이 2개 이상일 경우 getBean메소드와 동일하게 @Autowired도 NoUniqueBeanDefinitionException에러를 발생시킨다. 아래 코드를 보자. @Autowired private DiscountPolicy discountPolicy; //이때 DiscountPolicy메소드를 //RateDiscountPolicy와 FixDiscountPolicy라는 두 개의 클래스가 상속받고 있다고 하자. @Component public class FixDiscountPolicy implements DiscountPolicy() {...} @Component publ..
Ioc (Inversion of Control) 간단하게 말하면, 사용자의 new 선언을 방지하고, 모든 레퍼런스 변수, 관계설정, 제거, 사용까지 오브젝트(스프링 빈) 전반에 걸친 모든 과정을 프레임워크의 컨테이너(스프링 컨테이너)에게 위임하는 것. 이를 통해서 객체는 프레임워크가 관리하고, 사용자가 구현부를 관리함으로서 응집도를 높이고 결합도를 낮추며, 싱글톤 패턴을 유지할 수도 있다. 스프링은 패키지에서 스프링 빈으로 등록된 모든 메소드의 리턴값을 스캔(컴포넌트 스캔)하여 객체들을 관리하고, 의존관계를 주입해준다. 즉 스프링에서 말하는 DI는 객체 합성+객체를 관리할 컨테이너 패턴+IoC를 사용하는 스프링 프레임워크의 특징이라고 할 수 있다. 스프링에서 사용하는 IoC를 DI라고 하며, DI 말고..
EntityManagerFactory emf = Persistence.createEntityManagerFactory("project"); EntityManager em = emf.createEntityManager(); jpa에서 Entitymanagerfactory를 통해서 Entitymanager를 뽑아쓰는것과 다르게, 스프링에서는 스프링부트가 @PersistenceContext어노테이션만 달아주면 바로 EntityManager를 사용할 수 있게 해준다. @PersistenceContext EntityManager em; @Autowired가 스프링 빈을 주입한다면, @PersistenceContext는 영속성 콘텍스트를 주입하는 jpa 어노테이션이다. 이때 @PersistenceContext 대신..
개요 스프링을 이용하는 웹 애플리케이션의 경우 일반적으로 여러 클라이언트의 요청이 동시에 이루어진다. 그런데 싱글톤 방식을 사용하지 않는 컨테이너의 경우 고객의 요청이 올 때마다 객체를 새로 생성해야 한다. 이 대신 객체를 단 1개만 생성하고 공유하도록 하면 자원 낭비를 줄일 수 있다. 싱글톤 패턴 클래스의 인스턴스가 단 한개만 생성되도록 하는 디자인 패턴이다. 결국 한 개의 객체를 공유하도록 만들어 주어야 하는데, 이를 위해서 1. private static final 객체를 1개 생성후 static메서드를 통해서만 조회하게 한다. 2. 생성자는 private로 선언해서 외부에서 new키워드를 사용하지 못하게 한다. 와 같은 방법을 사용할 수 있다. static메서드를 통해서만 조회하도록만을 제한해도,..
프레임워크 vs 라이브러리 내가 작성한 코드를 제어하고, 대신 실행한다면(IoC) 그것은 프레임워크이고, 내가 작성한 코드가 직접 제어의 흐름을 담당한다면 라이브러리이다.스프링을 사용함으로서 범용의 프레임워크를 이용해서 개발을 진행할 수 있다. 스프링 컨테이너 ApplicationContext를 스프링 컨테이너라고 한다.스프링 컨테이너는 @Configuration 어노테이션이 붙은 AppConfig 전달받아 설정정보로 사용한다. 이때 @Bean이라 명시된 메소드를 모두 호출해서 반환된 객체를 메소드명으로 스프링 컨테이너에 등록한다. 이렇게 스프링 컨테이너에 등록된 객체를 스프링 빈이라고 한다.//스프링 컨테이너를 애노테이션 기반의 자바 설정 클래스로 설정ApplicationContext ac = n..
개요 DB에 접근하여 데이터를 수정하려면 쿼리를 DB로 날려주어야 한다. JPA를 사용하면 기본적인 SQL문이 자동으로 나가게 되긴 하지만, 직접 쿼리문을 작성하여 쿼리를 보내야 할 때를 위해 SQL을 추상화하여 만든 객체지향 SQL이 JPQL이다. JPQL은 SQL을 추상화했기 때문에 DB의 종류에 의존적이지 않다는 특징이 있다. (DB에 맞게 변환하는것은 jpa과 hibernate의 몫) 기본 활용법 JPQL의 문법은 SQL과 유사하다. SELECT, FROM, WHERE, GROUP BY, HAVING, JOIN등 SQL 문법을 모두 지원한다. 다만 테이블을 대상으로 쿼리를 작성하는 일반 SQL문과 다르게 JPQL은 jpa의 사용에 맞추어 엔티티 객체를 대상으로 쿼리를 작성할 수 있다. SELE..
JPA에는 엔티티 타입(@Entity로 정의하는 객체)과 값 타입(자바 객체나 primitive type)이 존재한다. 엔티티 타입은 데이터가 변해도 식별자로 추적할 수 있다(엔티티의 값을 변경한다고 해도 식별자를 이용해서 인식할 수 있다). 반대로 값 타입은 단순히 값으로서 사용하는 것으로서 jpa에서 추적하지 않는다. 아래에서는 여러가지 종류의 값 타입에 대해서 알아보겠다. 1. 기본값 타입 - Primitive type - 래퍼 클래스 - String 기본값 타입은 생명주기를 엔티티에 의존한다. 값 타입을 엔티티끼리 공유하게 되면 문제가 발생할 수 있으므로 같은 참조값을 가지면 안된다. (물론 자바의 primitive type같은 경우는 당연히 reference를 공유할 수 조차 없어 안전하다.) ..