VIRGIL ABLOH

스프링 컨텍스트 계층은 크게 나누면 자식 컨텍스트인 Servlet-WebApplicationContext가 있고 그의 부모인 Root-WebApplicationContext가 있다. Servlet-WebApplicationContext엔 주로 웹과 관련된 컨트롤러-뷰-헨들러가 있으며Root-WebApplicationContext엔 비즈니스 계층, DB 커넥터와 같은 공통적으로 사용하는 리소스에 대한 빈을 관리한다. 그래서 빈을 조회하면 먼저 자식 컨텍스트에서 조회를 하고 자식에게 빈이 없으면 부모 컨텍스트에서 조회를 하고 빈을 찾으면 자식 컨텍스트에게 주입하여 사용한다. http 요청시 동작방식(GPT 참고)HTTP 요청 → DispatcherServlet클라이언트가 /foo 같은 URL로 요청을 보내면..

REST는 Representational State Transfer의 약어로 하나의 URI는 하나의 고유한 리소르를 대표하도록 설계된다는 개념에 전송방식을 결합해서 원하는 작업을 지정한다.예를 들어 /boards/123은 게시물 중에서 123번이라는 고유한 의미를 가지도록 설계하고 이에 대한 처리는 GET,POST 방식과 같이 추가적인 정보를 통해서 결정한다.따라서 REST 방식은 다음과 같이 구성된다고 생각할 수 있다. 스프링은 @ReqeustMapping이나 @ResponseBody와 같이 REST 방식의 데이터 처리를 위한 여러 종류의 어노테이션과 기능이 있다.REST와 관련해서 알아 두어야 하는 어노테이션들은 다음과 같다. 어노테이션` 기능 @RestController Controller가 RES..

게시물 관리에서 마지막은 다양한 검색 처리이다. 검색 기능은 다시 검색 조건과 키워드로 나누어 생각해 볼 수 있다.검색 조건은 일반적으로 태그를 이용해서 작성하거나 를 이용하는 경우가 많다.과거에는 를 이용하는 경우가 더 많았지만 최근에는 일반 웹사이트에서 일반 사용자들의 경우에는 를 관리자용이나 검색 니응이 강한 경우 를 이용하는 형태가 대부분이다. 검색 기능과 SQL 게시물의 검색 기능은 다음과 같이 분류가 된다. 제목/내용/작성자와 같이 단일 항목 검색 제목or내용,제목or작성자,내용or작성자,제목or내용or작성자와 같은 다중 항목 검색 검색 항목은 제목/내용/작성자와 같은 단일 항목 검색과 제목 or 내용과 같이 복합적인 항목으로 검색하는 방식이 존재한다.게시물의 검색이 붙으면 가장 신경 쓰이는 ..

URL으니 파라미터를 이용해서 정상적으로 원하는 페이지로 이동하는 것을 확인했다면 화면 밑에 페이지 번호를 표시하고 사용자가 페이지 번호를 클릭할 수 있게 처리한다. 페이지를 보여주는 작업은 다음과 같은 과정을 통해서 진행한다. 브라우저 주소창에서 페이지 번호를 전달해서 결과를 확인하는 단꼐 JSP에서 페이지 번호를 출력하는 단계 각 페이지 번호에 클릭 이벤트 처리 전체 데이터 개수를 반영해서 페이지 번호 조절 패이지 처리는 단순히 링크의 연결이기 때문에 어렵지는 않지만 다음 그림과 같이 목록 페이지에서 조회 페이지,수정 삭제 페이지까지 페이지 번호가 계속해서 유지되어야만 하기 때문에 끝까지 싱경써야 하는 부분들이 많은 편이다.다음 그림은 페이지 번호에 어떤 작업을 하던 유지되면서 링크가 연결되는 모습이..

MyBatis는 SQL을 그대로 사용할 수 있기 때문에 인라인뷰를 이용하는 SQL을 작성하고 필요한 파라미터를 지정하는 방식으로 페이징 처리를 하게 된다.여기서 신경써야 하는 점은 페이징 처리를 위해서는 SQL을 실행할 때 몇 가지 파라미터가 필요하다는 점이다. 페이징 처리를 위해서 필요한 파라미터는 페이지 번호 한 페이지당 몇 개의 데이터를 보여줄 것인지가 결정되어야만 한다. 페이지 번호와 몇 개의 데이터가 필요한지를 별도의 파라미터로 전달하는 방식도 나쁘지는 않지만 아예 이 데이터들을 하나의 객체로 묶어서 전달하는 방식이 나중을 생각하면 좀 더 확장성이 좋다. com.osk2090.domain 패키지에 Criteria 이름의 클래스를 작성한다.Criteria는 검색의 기준을 의미한다. Criteria..

구현된 기능들 중 가장 미숙한 부분은 목록 페이지이다.목록 페이지는 기본적으로 페이징처리가 필요한데 상식적으로 생각해 봐도 수많은 데이터를 한 페이지에서 보여주면 처리 성능에 영향을 미친다.또한 브라우저에서도 역시 데이터의 양이나 처리 속도에 문제를 일으키게 된다. 일반적으로 페이징 처리는 크게 번호를 이용하거나 계속 보기의 형태로 구현된다. 번호를 이용한 페이징 처리는 과거 웹 초기부터 이어오던 방식이고,계속보기는 Ajax와 앱이 등장한 이우헤 무한 스크롤이나 더보기와 같은 형태로 구현된다. 오라클에서 페이징 처리하는 것은 MySQL에 비해서 추가적인 지식이 필요하다. oerder by의 문제 프로그램을 이용해서 정렬을 해 본적이 있다면 데이터의 양이 많을수록 정렬이라는 작업이 얼마나 많은 리소스를 소..

화면을 개발하기 전에는 반드시 화면의 전체 레이아웃이나 디자인이 반영된 상태에서 개발하는 것을 추천한다. 일부 개발자들은 화면을 나중에 처리한다고 생각하고 진행하는 경우가 있는데 결과적으로는 두 배의 시간을 들이는 결과가 될 가능성이 높기 때문에 권장하지는 않는다. 목록 페이지 작업과 includes 스프링 MVC의 JSP를 처리하는 설정은 Java기준으로 ServletConfig.class @Override public void configureViewResolvers(ViewResolverRegistry registry) { InternalResourceViewResolver bean = new InternalResourceViewResolver(); bean.setViewClass(JstlView...

비즈니스 계층의 구현까지 모든 테스트가 진행되었다면 이제 남은 작업은 프레젠테이션 계층인 웹의 구현이다. Controller의 작성 스프링 MVC의 Controller는 하나의 클래스 내에서 여러 메서드를 작성하고, @ResquestMapping 등을 이용해서 URL을 분기하는 구조로 작성할 수 있기 때문에 하나의 클래스에서 필요한 만큼 메서드의 분기를 이용하는 구조로 작성한다. 과거에는 이 단계에서 Tomcat(WAS)을 실행하고 웹 화면을 만들어서 결과를 확인하는 방식의 코드를 작성해 왔다. 이 방식은 시간도 오래 걸리거니와 테스트를 자동화 하기에 어려움이 많다. 따라서 이 단계에서는 WAS를 실행하지 않고 Controller를 테스트할 수 있는 방법으로 진행하겠다. BoardController의 분..

비즈니스 계층 비즈니스 계층은 고객의 요구사항을 반영하는 계층으로 프레젠테이션 계층과 영속 계층의 중간 다리 역할을 하게 된다. 영속 예층은 데이터베이스를 기준으로 해서 처리하게 된다. 예컨데,'쇼핑몰에서 상품을 구매한다'고 가정해 보자.해당 쇼핑몰의 로직이 '물건을 구매한 회원에게는 포인트를 올려준다'고 하면 영속 계층의 설계는 '삼품'과 '회원'으로 나누어서 설계하게 된다.반면에 비즈니스 계층은 상품 영역과 회원 영역을 동시에 사용해서 하나의 로직을 처리하게 되므로 다음과 같은 구조로 만들게 된다. 현재 예제는 단일한 테이블을 이용하고 있기 때문에 위와 같은 구조는 아니지만 설계를 할때는 원칙적으로 영역을 구분해서 작성해야 한다.일반적으로 비즈니스 영역에 있는 객체들은 서비르사는 용어를 많이 사용한다..

영속/비즈니스 계층의 CRUD 구현 코드를 이용해서 데이터에 대한 CRUD 작업을 진행한다. 다음과 같은 순서로 진행한다. 테이블의 칼럼 구조를 반영하는 VO(Value Object) 클래스의 생성 MyBatis의 Mapper 인터페이스의 작성/XML 처리 작성한 Mapper 인터페이스의 테스트 위의 과정 전에 먼저 JDBC 연결을 테스트하는 과정을 거치는 것이 좋지만 SQL Developer의 연결 자체가 이미 JDBC 연결되어 있다는 것이므로 이대로 진행한다. 영속 예측의 구현 준비 거의 모든 웹 애플리케이션의 최종 목적은 데이터베이스에 데이터를 기록하거나, 원하는 데이터를 가져오는 것이 목적이기 때문에 개발할 때 어느 정도의 설계가 진행되면 데이터 베이스 관련 작업을 하게 된다. VO 클래스의 작성..