빠에야는 개발중

무엇인가? @Transactional 어노테이션은 스프링에서 제공하는 클래스, 메소드 레벨의 트랜잭션 지원 어노테이션이다. 이 어노테이션이 선언되면 스프링은 프록시 객체를 생성하여 자동 commit, rollback 등의 트랜잭션 처리를 맡긴다. 클래스, 메소드 내에서 Persistence layer에 접근하여 데이터를 조작, 조회 할 때 사용한다. 주로 Service layer에서 사용하게된다. 트랜잭션 격리 수준 트랜잭션 어노테이션답게 트랜잭션의 기능들 중 하나인 격리 수준 속성을 가지고 있다. Default 기본 격리 수준(DB의 격리 수준을 따름) READ_UNCOMMITTED (Level 0) 커밋되지 않은 데이터 읽기 허용 변경 중인 데이터에 접근할 수 있다. Dirty read 문제가 발생할..

롬복은 스프링에서 사용되는 라이브러리로, 어노테이션을 기반으로 반복적이고 따분한 작업들을 대폭 줄여주어 편하게 개발할 수 있게 도와준다. 대표적으로 Getter와 Setter 등이 있다. 한번 사용해보자. maven dependency를 설정해주는 것 만으로도 적용할 수 있다.123456 org.projectlombok lombok 1.16.8 providedcs 이제 적용된 코드를 살펴보자. 롬복을 적용하기 전에는 아래와 같이 길던 코드가..1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787..

실습을 진행하면서 Controller의 메소드들 중 getBoard와 getBoardList의 리턴형이 ModelAndView였던 것을 String으로 통일시켜주는 부분이 있었다. 코드의 깔끔함이라는 관점에서는 납득을 하였지만, 정확히 어떻게 작동을 하는지는 확인해보지 않고 넘어갔었다. 이 부분을 짚고 넘어가고 싶었다. getBoardList 메소드의 코드를 살펴보면1234567891011@RequestMapping("/getBoardList.do")public String getBoardList(BoardVO vo, Model model) { if(vo.getSearchCondition() == null) { vo.setSearchCondition("TITLE"); } if(vo.getSearchKey..

JPA 이번에는 JPA를 사용해보자. ORM은 쿼리를 자동으로 생성해주는 등 편리한 점이 많기 때문에 꼭 써봐야겠다고 생각했다. 입문 저번처럼 스프링에 적용하기 전에 연습을 해보자. 먼저 maven 프로젝트를 하나 생성하고, 디펜던시 설정을 해준다. Project facets에 JPA를 체크하면 persistence.xml 파일이 자동으로 생성된다. 여기에 클래스 등록을 해준다.12345 com.springbook.biz.board.BoardVO//생략Colored by Color Scriptercs 다음은 엔티티 작성이다. @Entity 어노테이션을 사용하여 VO와 거의 동일하게 작성해준다.12345678910111213141516171819202122232425262728293031package co..

Mybatis 적용 마지막 챕터는 퍼시스턴스 레이어에 대해서 다룬다. 먼저 mybatis를 사용하여 굉장히 보기 싫었던 JDBC 접속 코드를 깔끔하게 만들자. 입문 스프링에 적용하기 전에 별도의 프로젝트를 만들어 적응해보고자 한다. 먼저 디펜던시를 설정해주고, IDE 마켓에서 java orm plugin을 설치해준다. 이녀석이 있으면 편하게 xml 파일을 만들 수 있다. VO는 기존 스프링 프로젝트에서 사용하던 BoardVO를 그대로 사용한다. 다음은 mapper xml을 작성한다. 파라미터의 물음표를 이름으로 바꿔주는 것 외에는 별다른 작업이 필요없다.1234567891011121314151617181920212223242526272829 insert into board(seq, title, write..

비즈니스 레이어 통합 그동안 진행하면서 컨트롤러가 DAO 객체를 직접 가져다 쓰는 코드를 짰었는데, 이런 코드는 좋지 않기 때문에 개선하고자 한다. 우선 그 이유부터 알아보자. 왜 안되는가? 상황 1 : 만약 기존의 DAO가 다른 클래스로 교체된다면? DAO를 참조하고 있는 모든 컨트롤러의 코드를 수정해야만 한다. 상황 2 : AOP를 사용하고 싶다. 그런데 AOP의 동작 시점인 비즈니스 메소드가 호출되지 않기 때문에 어드바이스도 호출되지 않는다. 실제로 지금까지의 코드에서는 AOP 설정을 해놨던 메소드가 전혀 호출되지 않고 있었다. 상황 1의 경우는 OCP를 위반하고 있다. 변경이 일어날 때마다 모든 부분을 수정하기 때문이다. 이는 추상화를 통하여 해결할 수 있다. 상황 2는 비즈니스 레이어를 강요하고..

어노테이션 기반 MVC 스프링은 xml을 통한 설정이 많다. 그래서 xml의 볼륨이 커지기 쉽고 비례적으로 복잡해진다. 따라서 이번에는 어노테이션 설정을 통해서 xml 파일을 날씬하게 만들어본다. 컨트롤러 설정 우선 presentation-layer.xml의 컨트롤러, handler mapping, view resolver 설정을 모두 지우고, 으로 대체한다. 패키지는 com.springbook.view로 설정한다.1234567891011 Colored by Color Scriptercs 그 다음 각 컨트롤러들을 하나로 모아서 BoardController로 묶어준 뒤, @Controller 어노테이션을 붙여준다. 이것만으로도 해당 클래스는 스프링 컨테이너에 의해 컨트롤러로 인식된다. @RequestMap..

Model2로 개선해보자 앞서 만든 게시판은 model1로서 뷰와 컨트롤러가 jsp에 모두 일임 되어있는 구조였다. 이는 유지보수에 매우 부적합한 형태이기 때문에 개선할 필요가 있다. 따라서 이번에는 model2로의 발전을 도모해본다. model2는 model1에서 컨트롤러를 따로 빼낸 형태이다. jsp이 가진 복수의 역할이 분리되므로 깔끔하고 이해하기 쉬운 코드가 될 수 있다. 12345678910111213 action action com.springbook.view.controller.DispatcherServlet contextConfigLocation /WEB-INF/config/presentation-layer.xml action *.doColored by Color Scriptercs우선 w..

Model1 아키텍처로 게시판 개발 스프링 MVC를 사용하기 전에 어떤 식으로 아키텍처가 발전해왔는지를 알아보기 위해 구식 아키텍처부터 사용해보기로 했다. 이런 작업은 이전에도 한적이 있었는데 도중에 어떤 이유로 실패했기 때문에 다시 해보는 것이다. (무슨 이유였는지는 잊어버렸다…) 우선 model1부터 시작해보겠다. Model1은 jsp에서 컨트롤러와 뷰를 모두 담당하는 것이다. 사실 컨트롤러라는 개념이 나중에 나왔으므로 반대로 말한 것이지만 이해하기 편하니까 이렇게 말하겠다. 요청을 받고 데이터를 조작하여 렌더링하는 것까지 모두 jsp에서 이루어지는 모델인데 굉장히, 굉장히 보기 불편하고 짜기도 귀찮게 생겼다. 책을 보고 그대로 옮겨서 타이핑하는 작업임에도 재미없고 지루함을 느꼈다. 그리고 구조 자체..

Spring JDBC 이번에는 스프링 JDBC를 사용해서 DB와 연동해보자. 기존 JDBC에서는 개발자가 연결을 모두 담당하여 번거롭고 긴 코드를 짜고 관리해야만 했다. 이를 해결하기 위해서 스프링 JDBC를 적용하면 개발자는 연결에 대해 알 필요가 없어지고 쿼리에만 집중할 수 있게 된다. 먼저 JDBCTemplate 클래스 설정을 해주자. 우선 dataSource를 설정해야한다. xml 코드들과 properties 파일 정보 빈 등록을 해주었기 때문에 Autowired 어노테이션으로 의존성을 주입하여 사용하기만 하면 된다.이전에 사용하던 JDBC 코드보다 훨씬 깔끔한 것을 알 수 있다. 이번에 사용한 jdbcTemplate은 RowMapper를 사용하여 객체 매핑을 해줘야한다. 이전에 사용해보았던 sq..