기록하는 개발자

필터 필터는 서블릿이 지원하는 수문장입니다. 즉 서블릿으로 진행하는 조건을 판단할 수 있다는 것입니다. 먼저 필터의 흐름은 다음과 같습니다 HTTP 요청 -> WAS -> 필터 -> 서블릿 -> 컨트롤러 필터를 적용하면 필터가 호출된 다음에 서블릿이 호출됩니다. 그래서 모든 고객의 요청 로그를 남기는 요구사항이 있다면 필터를 사용하면 모든 요청 로그를 남길 수 있습니다. 스프링을 사용하는 경우 여기서 말하는 서블릿은 dispatcherServlet 으로 생각하면 됩니다. 필터에서 적절하지 않은 요청이라고 판단되면 거기에서 끝을 낼 수도 있습니다. 즉 필터에서 서블릿으로 더 이상 요청을 전달하지 않는다는 것입니다. 예를 들어 로그인 여부를 체크하는 경우 필터에서 판단하여 로그인 한 사용자라면 컨트롤러까지 ..

로그인 상태 유지하기 웹 브라우저랑 서버 사이에서 로그인 했다는 것이 유지가 되어야한다. 쿼리 파라미터를 계속 유지하는 것은 어렵고 비효율적이므로 쿠키를 사용한다. 쿠키 서버에서 로그인에 성공하면 http 응답에 쿠키를 담아서 브라우저에 전달한다. 그러면 브라우저는 앞으로 해당 쿠키를 지속해서 보내준다. 쿠키에는 영속 쿠키와 세션 쿠키가 있다 영속 쿠키: 만료 날짜를 입력하면 해당 날짜까지 유지 세션 쿠키: 만료 날짜를 생략하면 브라우저 종료시 까지만 유지 브라우저 종료시 로그아웃이 되길 기대하므로, 우리에게 필요한 것은 세션 쿠키이다. 쿠키와 보안문제 쿠키의 값이 임의로 변경될 수 있다 이런식으로 개발해버리면 사용자 모두가 털릴 수 있다 ! 실제 개발자모드에서 쿠키를 마음대로 바꿀 수 있다 쿠키에 보관..

Validation 객체를 생성하거나 수정하는 등의 작업을 할 때 올바르지 않은 데이터를 걸러내고 유지하기 위해 데이터 검증이 적용됩니다. Client Side 뿐만 아니라 Server Side에서도 데이터 유효성을 반드시 검사해야합니다. 클라이언트 쪽에서 데이터를 변조하여 서버로 쉽게 보낼 수 있는 상황이 생길 수 있기 때문에 반드시 서버측에서도 데이터 유효성 검사를 실시해야합니다. 스프링에서는 @validated 에노테이션을 이용하여 검증할 수 있습니다. 그러나 검증 기능을 매번 코드로 작성하는 것은 번거롭습니다. 객체 값 하나하나를 If 문을 통해서 검증하는 것은 코드를 작성하는 과정에서 반복적이고 효율적이지 않습니다. 게다가 특정 필드에 대한 검증 로직은 대부분 빈 값(Null)인지 아닌지, 특정..

Model 스프링에서 모델 객체는 컨트롤러에서 생성된 데이터를 담아 View로 전달할 때 사용하는 객체이다. Model 객체를 model이라고 하면 model.addAttribute("key", "value") 형태의 메소드를 이용해 view에 데이터를 전달한다. @GetMapping("/{itemId}") public String item(@PathVariable long itemId, Model model) { Item item = itemRepository.findById(itemId); model.addAttribute("item", item); return "form/item"; } @ModelAttribute 등록, 조회, 수정 폼에서 모두 공통된 데이터를 보여주어야 하는 경우에 어노테이션을 ..

V2에서 컨트롤러가 반드시 HttpServletRequest, HttpServletResponse가 사용된다는 아쉬운 점이 있었다. 컨트롤러 입장에서 HttpServletRequest, HttpServletResponse가 꼭 필요하지 않다. 각 컨트롤러에서 service 함수를 보면 request, response는 전혀 사용하지 않고 MyView객체만 반환하고 있다. 요청 파라미터 정보는 자바의 Map으로 대신 넘기도록 하면 지금 구조에서는 컨트롤러가 서블릿 기술을 몰라도 동작할 수 있다. 그리고 request 객체를 Model로 사용하는 대신에 별도의 Model 객체를 만들어서 반환하면 된다. 컨트롤러가 서블릿 기술을 전혀 사용하지 않도록 V3 버젼을 만들어보자. 뷰 이름 중복 제거 컨트롤러에서 지..

MVC 패턴 개선점 앞서 소개한 MVC 패턴을 적용한 코드에서 컨트롤러의 역할과 뷰를 렌더링하는 역할을 명확하게 구분할 수 있었다. 특히 뷰는 화면을 그리는 역할에 충실한 덕분에, 코드가 깔끔하고 직관적이다. 단순하게 모델에서 필요한 데이터를 꺼내고 화면을 만드는 역할을 한 것이다. 그런데 컨트롤러는 코드만 딱 봐도 중복이 많고 필요하지 않는 코드들도 많이 보인다. 1. 포워드 중복 View로 이동하는 코드가 항상 중복호출 되었다. 물론 중복으로 호출하는 부분을 함수화하여 공통화해도 되지만, 해당 함수도 항상 직접 호출해야 한다. RequestDispatcher dispatcher = request.getRequestDispatcher(viewPath); dispatcher.forward(request,..

MVC 패턴 - 개요 각자 자기가 맡은 일만 하자! 하나의 서블릿이나 JSP만으로 비즈니스 로직과 뷰 렌더링까지 모두 처리하게 되면, 너무 많은 역할을 하게되고 결과적으로 유지보수하기 어려워진다. 비즈니스 로직을 호출하는 부분에 변경이 발생해도 해당 코드를 손대야 하고, UI를 변경할 일이 있어도 비즈니스 로직이 함께 있는 해당 파일을 수정해야한다. 즉, 하나의 파일 안에 비즈니스 로직 코드와 UI를 담당하는 코드가 함께 있다는 것이다. HTML 코드 하나 수정하는데 수백줄의 비즈니스 로직 코드가 함께 있는 것은 매우 비효율적이고, 이와 반대의 경우에도 정말 비효율적이다. 이를 현실에서 비유해보면 경찰서에서 소방업무까지 담당하고 있다면..? 생각만 해도 혼란스럽다 JSP같은 뷰 템플릿은 화면을 렌더링 하..

What is Servlet and JSP ? 스프링 MVC패턴을 공부하기 위해서 서블릿과 JSP의 이해는 필수적이다. 스프링이 탄생한 배경의 이유 중 하나로 서블릿과 JSP가 관련되어있다. HTTP 통신 기반의 클래스를 살펴보면 어노테이션 기반으로든, 파라미터로든 서블릿 클래스가 활용된다는 것을 알 수 잇다. 서블릿은 클래스 내부에 직접 HTML 코드를 작성하여 요청에 대한 응답한다. HTML을 코딩하기 너무 어렵고 불편해서 HTML 내부에 Java코드를 삽입하는 형식이 JSP이다. 다시 말해 서블릿의 단점을 보완하고자 만든 서블릿 기반의 스크립트 기술이다. 서블릿을 이용하게 되면 웹프로그래밍을 할 수 있지만 자바에 대한 지식이 필요하며 화면 인터페이스 구현에 너무 많은 코드를 필요로 하는 등 비효율적..

의존관계를 주입하는 방법은 크게 4가지가 있다. 1. 생성자 주입(Constructor) 2. 수정자 주입(Setter) 3. 필드 주입 4. 일반 메서드 주입 생성자 주입 생성자 주입은 말 그대로 생성자를 통해서 의존관계를 주입 받는 방법이다. 생성자 호출시점에 딱 1번만 호출되는 것이 보장된다. 불변, 필수 의존관계에 사용한다. 앞에서 설명했던 OrderServiceImpl 클래스를 보면, 클래스 내부 멤버 변수들이 private final로 선언된 것을 볼 수 있다. final로 선언된 멤버 변수들은 반드시 생성자 주입을 통해 생성자 호출시점에 딱 1번 호출되어야 한다. final로 선언된 변수는 값을 절대로 변경할 수 없기 때문에 최초에 생성되는 시점에 정의한다. 생성자가 1개 존재하는 경우에는 ..

지금까지 스프링 빈 설정을 하는 과정을 살펴보면 AppConfig 클래스에 @Configuration 어노테이션을 설정한 후 @Bean을 통해서 직접 등록할 스프링 빈을 설정했다. 앞서 보인 예제는 몇 개 되지 않아 일일이 입력하였지만, 빈 객체가 많아지는 경우 일일이 선언해주기 어렵다(귀찮다) 또 실수로 빈 설정을 누락하는 경우 스프링 컨테이너에 빈 객체가 등록되지 않을 수도 있다. 그러므로 스프링은 설정 정보 없이 자동으로 스프링 빈을 등록하는 컴포넌트 스캔(@Component Scan)을 제공한다. 또한 의존관계를 자동으로 주입하는 @Autowired라는 기능도 제공한다 @ComponentScan, @Autowired 사용하기 우선 컴포넌트 스캔을 사용하려면 @ComponentScan을 설정 정보에..