silverchaeJ
commented
3 months ago Chapter15 간단한 웹 어플리케이션 구조
1.웹 어플리케이션의 구성 요성
웹 어플리케이션을 개발할 때 사용하는 전형적인 구조는 다음 요소를 포함한다.
- 프론트 서블릿
- 컨트롤러 + 뷰
- 서비스
-
DAO
프론트 서블릿의 역할
- 프론트 서블릿은 웹 브라우저의 모든 요청을 받는 창구
-
프론트 서블릿은 요청을 분석해서 알맞은 컨트롤러에 전달 ( 스프링 MVC에서는 DispatcherServlet이 프론트 서블릿의 역할을 수행한다.)
[웹 어플리케이션의 구조]
컨트롤러는 실제 웹 브라우저의 요청을 처리한다. 지금까지 구현해본 스프링 컨트롤러가 이에 해당한다. 컨트롤러는 클라이언트(브라우저)의 요청을 처리하기 위해 알맞은 기능을 실행하고 그 결과를 뷰에 전달한다.
(이해를 돕기위한 예시사진)
컨트롤러의 주요 역할
- 클라이언트가 요구한 기능을 실행
- 응답 결과를 생성하는데 필요한 모델 생성
- 응답 결과를 생성할 뷰 선택
컨트롤러는 로직 실행을 위해 서비스에 위임한다. 컨트롤러는 어플리케이션이 제공하는 기능과 사용자 요청을 연결하는 매개체이고, 기능 제공을 위한 로직을 직접 수행하지 않는다.
@PostMapping
public String submit(
@ModelAttribute("command") ChangePwdCommand pwdCmd,
Errors errors,
HttpSession session){
new ChangePwdCommandValidator().validate(pwdCmd, errors);
if(errors.hasErrors()){
return "edit/changePwdForm";
}
AuthInfo authInfo = (AuthInfo) session.getAttribute("authInfo");
try{
//컨트롤러는 로직 실행을 서비스에 위임
changePasswordService.changePassword(
authInfo.getEmail(),
pwdCmd.getCurrendPassword(),
pwdCmd.getNewPassword());
return "edit/changePwd";
}catch(IdPasswordNotMatchingException e){
errors.rejectValue("currentPassword", "notMatching");
return "edit/changePwdForm";
}
}위에 코드는 ChangePasswordService에 비밀번호 변경 처리를 위임했다
서비스의 역할
- 서비스는 기능의 로직을 구현
- DB와 웹 어플리케이션 간에 데이터를 이동시켜주는 역할 (서비스는 DB연동이 필요하면 DAO를 사용)
2.서비스의 구현
서비스는 핵심이 되는 기능의 로직을 제공한다.
예를 들어 비밀번호 변경 기능은 아래와 같은 로직을 서비스에서 수행한다.
- DB에서 비밀번호를 변경할 회원의 데이터를 구한다.
- 존재하지 않으면 익셉션을 발생시킨다.
- 회원 데이터의 비밀번호를 변경한다.
- 변경 내역을 DB에 반영한다.
🤔서비스 메서드를 트랙잭션 범위에서 실행해야 하는 이유
->웹 어플리케이션을 사용하든 명령행에서 실행하든 비밀번호 변경 기능을 위해서 서비스는 동일한 로직을 수행하는데 중간에 실패하면 이전까지 했던 것을 취소해야 하고, 모든 과정을 성공적으로 진행했을 때 완료해야하기 때문이다.
@Transactional
public void changePassword(String email, String oldPwd, String newPwd){
Member member = memberDao.selectByEmail(email);
if(member==null)
throw new MemberNotFoundException();
member.changePassword(oldPwd, newPwd);
memberDao.update(member);
}같은 데이터를 사용하는 기능들을 한 개의 서비스 클래스에 모아서 구현할 수 있다.
예를 들어 회원 가입 기능과 비밀번호 변경 기능은 모두 회원에 대한 기능이므로 다음과 같이 MemberService 클래스에 기능을 구현할 수 있다.
public class MemberService{
@Transactional
public void regist(RegisterRequest req){...}
@Transactional
public void changePassword(String email, String lodPwd, String newPwd){...}
}회원가입 기능은 RegisterRequest 클래스를 파라미터로 사용했다.
필요한 데이터를 전달받기 위해 별도 타입을 만들면 스프링 MVC의 커맨드 객체로 해당 타입을 사용할 수 있어 편하다.
회원 가입 요청을 처리하는 컨트롤러 클래스의 코드는 다음과 같이 서비스 메서드의 입력 파라미터로 사용되는 타입을 커맨드 객체로 사용했다.
@PostMapping("/register/step3")
public String handleSteo3(RegisterRequest regReq, Errors errors){
...
memberRegisterService.regist(regReq);
...
}비밀번호 변경의 changePassword() 메서드처럼 웹 요청 파라미터를 커맨드 객체로 받고 커맨드 객체의 프로퍼티를 서비스 메서드에 인자로 전달할 수도 있다.
@RequestMapping(method=RequestMethod.POST)
public String submit(@ModelAttribute("command") ChangePwdCommand pwdCmd, Errors errors, HttpSession session){
...
changePasswordService.changePassword(
authInfo.getEmail(),
pwdCmd.getCurrentPassword(),
pwdCmd.getNewPassword()
);
...
}커맨드 클래스를 작성한 이유는 스프링 MVC가 제공하는 폼 값 바인딩과 검증, 스프링 폼 태그와의 연동 기능을 사용하기 위함이다.
3.컨트롤러에서 DAO접근
서비스 메서드에서는 어떤 로직도 수행하지 않고 단순히 DAO의 메서드만 호출하고 끝나는 경우도 있다.
예를 들어 회원 데이터 조회를 위한 서비스 메서드를 다음과 같이 구현하곤 한다.
public class MemberSerivce{
...
public Member getMember(Long id){
return memberDao.selectById(id);
}
}여기서 MemberService 클래스의 getMember() 메서드는 MemberDao의 selectByID()만 실행할 뿐 추가 로직은 없다.
컨트롤러 클래스는 이 서비스 메서드를 통해 회원 정보를 구한다.
@RequestMapping("/member/detail/{id}")
public String detail(@PathVariable("id") Long id, Model model){
//사실상 DAO를 직접 호출하는 것과 동일
Member member = memberService.getMember(id);
//Member member = memberDao.selectByEmail(id);
if(member==null)
return "member/noFound";
model.addAttribute("member",member);
return "member/memberDatail";
}4.패키지 구성
패키지의 구성을 조금 더 정확하게 분리하면 아래 그림처럼 '웹 요청을 처리하기 위한 것'과 '기능을 제공하기 위한 것'으로 구분할 수 있다.
웹 요청을 처리하기 위한 영역
- 컨트롤러: 사용자의 요청을 받아들이고, 요청에 맞는 서비스를 호출하며, 결과를 뷰로 전달합니다.
- Validator: 커맨드 객체의 값을 검증합니다.
- 커맨드 객체: 폼 데이터를 담는 객체입니다. 이 패키지는 보통 web.member와 같은 형태로 구성합니다.
기능 제공 영역
이 영역에는 실제 비즈니스 로직과 데이터 처리를 담당하는 클래스들이 위치합니다:
- 서비스: 비즈니스 로직을 처리합니다.
- DAO: 데이터베이스와 상호작용하여 데이터를 처리합니다.
-
모델: 도메인 객체로, 비즈니스 데이터를 담는 객체입니다. 이 패키지는 보통 domain.member와 같은 형태로 구성합니다. 기능 영역은 더 세부적으로 service, dao, model과 같이 나눌 수 있습니다.
기능 영역은 다음과 같이 service, dao,model 같은 세부 패키지로 구분하기도 한다.
도메인 주도 설계(DDD)의 적용
:도메인 주도 설계는 복잡한 애플리케이션의 구조를 체계적으로 관리하기 위한 방법론입니다. DDD에서는 애플리케이션을 UI, 서비스, 도메인, 인프라의 네 영역으로 나눕니다
- UI (User Interface):
역할: 사용자와의 상호작용을 담당합니다.
구성 요소: 컨트롤러, 뷰
예시: web.member 패키지
- 서비스 (Service):
역할: 도메인 로직을 조정하고 트랜잭션을 관리합니다.
구성 요소: 애플리케이션 서비스
예시: domain.member.service 패키지
- 도메인 (Domain):
역할: 핵심 비즈니스 로직과 규칙을 포함합니다.
구성 요소: 도메인 모델, 엔티티, 밸류 오브젝트, 도메인 이벤트, 애그리게잇
예시: domain.member.model 패키지
- 인프라 (Infrastructure):
역할: 데이터베이스와의 상호작용을 담당합니다.
구성 요소: 리포지토리, DAO, 외부 시스템과의 통신
예시: domain.member.dao 패키지
DDD의 장점
- 코드의 일관성 유지: 도메인 모델과 비즈니스 로직이 잘 정의되어 있어 코드가 복잡해져도 일관성을 유지할 수 있습니다.
- 유지 보수성 향상: 비즈니스 로직이 서비스가 아닌 도메인 모델에 집중되어 있어, 변경 사항이 발생해도 쉽게 관리할 수 있습니다.
- 확장성: 새로운 기능 추가나 변경이 발생해도 구조가 잘 정의되어 있어 확장이 용이합니다.
chapter16 JSON 응답과 요청 처리
1.JSON 개요
Jackson은 자바 객체와 JSON 형식 문자열 간 변환을 처리하는 라이브러리이다.
스프링 MVC에서 Jackson 라이브러리를 이용해서 자바 객체를 JSON으로 변환하려면 클래스 패스에 Jackson 라이브러리를 추가하면 된다.
2.JSON 의존 설정
Jackson은 아래 그림과 같이 자바 객체와 JSON 사이의 변환을 처리한다.
3.@RestController로 JSON 형식 응답
스프링 MVC에서 JSON 형식으로 데이터를 응답하기 위해선 @Controller 대신 @RestController 어노테이션을 사용하면 된다.
@RestController
public class RestMemberController{
private MemberDao memberDao;
private MemberRegisterService registerService;
@GetMapping("/api/members")
public List<Member> members(){
return memberDao.selectAll();
}
@GetMapping("/api/members/{id}")
public Member member(@PathVariable Long id, HttpServletResponse response) throws IOException{
...
}
...
}@RestController 어노테이션을 붙이면 스프링 MVC는 요청 매핑 어노테이션을 붙인 메서드가 리턴한 객체를 알맞은 형식으로 변환해서 응답데이터로 전송한다. 이때 Jackson을 사용하면 JSON 형식의 문자열로 변환해서 응답한다. 리턴 타입이 List
인 경우에 List 객체를 JSON 형식의 배열로 변환한 결과이다.
@RestController 어노테이션이 추가되기 전에는 다음과 같이 @Controller 어노테이션과 @ResponseBody 어노테이션을 사용했다.
@Controller public class RestMemberController{ private MemberDao memberDao; private MemberRegisterService registerService; @RequestMapping(path="/api/members", method=RequestMethod.GET) @ResponseBody public List<Member> members(){ return memberDao.selectAll(); } }3.1 JsonIgnore를 이용한 제외 처리
응답 결과에 password가 포함되어 있으면 안되기 때문에 응답 결과에서 제외시켜야 한다.
Jackson이 제공하는 @JsonIgnore 어노테이션을 사용하면 이를 간단히 처리할 수 있다.
다음과 같이 JSON 응답에 포함시키지 않을 대상에 어노테이션을 붙인다.
public class Member{
private Long id;
private String email;
@JsonIgnore
private String password;
private String name;
private LocalDateTime registerDateTime;
}3.2 날짜 형식 변환 처리: @JsonFormat 사용
Jackson에서 날짜나 시간 값을 특정한 형식으로 표현하는 가장 쉬운 방법은 @JsonFormat을 사용하는 것이다.
public class Member{
private Long id;
private String email;
private String name;
@JsonFormat(pattern="yyyyMMddHHmmss")
private LocalDateTime registerDateTime;
}Json 응답 결과는 다음과 같다.
{
"id":1,
"email":"abc@gmail.com",
"name:"spring",
"registerDateTime":"202208150130"
}3.3 날짜 형식 변환 처리 : 기본 적용 설정
스프링 MVC는 자바 객체를 HTTP 응답으로 변환할 때 HttpMessageConverter라는 것을 사용한다.
JSON으로 변환할 때 사용하는 컨버터를 새롭게 등록해서 날짜 형식을 원하는 형태로 변환하도록 설정하면 모든 날짜 형식에 동일한 변환 규칙을 적용할 수 있다.
@Configuration
@EnableWebMvc
public class MvcConfig implements WebMvcConfiguration{
...
@Override
public viod extendMessageConverter{
List<HttpMessageConverter<?>> converters){
ObjectMapper objectMapper = Jackson2ObjectMapperBuilder
.json()
.featuresToDisable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS)
.build();
converters.add(0,new MappingJackson2HttpMessageConverter(objectMapper));
}
}
}3.4 응답 데이터의 컨텐츠 형식
응답 헤더의 Content-type이 application/json인 것을 알 수 있다.
Content-Type: application/json
4.@RequestBody로 JSON 요청 처리
POST, PUT 방식을 사용하면 name=이름&age=20과 같은 쿼리 문자열 형식이 아니라 다음과 같은 JSON 형식의 데이터를 요청 데이터로 전송할 수 있다.
{"name":"이름", "age":20}
JSON 형식으로 전송된 요청 데이터를 커맨드 객체로 전달받는 방법은 커맨드 객체에 @RequestBody 어노테이션을 붙이면 된다.
@RestController{
...
@PostMapping("/api/members")
public void new Member(@RequestBody @Valid RegisterRequest regReq, HttpServletResponse response){
...
}
}4.1 JSON 데이터의 날짜 형식 다루기
특정 패턴을 가진 문자열을 LocalDateTime이나 Date 타입으로 변환하고 싶다면 @JsonFormat 어노테이션의 pattern 속성을 이용해서 패턴을 지정한다.
@JsonFormat(pattern="yyyyMMddHHmmss")
private LocalDateTime birthDateTime;
@JsonFormat(pattern="yyyyMMdd HHmmss")
private Date birthDate;4.2 요청 객체 검증하기
newMember()의 regReq 파라미터에 @Valid 어노테이션이 붙어있다.
JSON 형식으로 전송한 데이터를 변환한 객체도 동일한 방식으로 @Valid 어노테이션이나 별도 Validator를 이용해서 검증할 수 있다.
Validator를 사용할 경우 직접 상태 코드를 처리해야 한다.
import org.springframework.validation.annotation.Validated;
import org.springframework.web.bind.annotation.*;
import org.springframework.web.server.ResponseStatusException;
import org.springframework.http.HttpStatus;
@RestController
@Validated
public class RestMemberController {
// ... 필드 선언 및 의존성 주입
@PostMapping("/api/members")
public void newMember(@RequestBody RegisterRequest regReq, HttpServletResponse response) {
// 커스텀 Validator를 사용하여 요청 데이터를 검증
if (!isValid(regReq)) {
throw new ResponseStatusException(HttpStatus.BAD_REQUEST, "Invalid request data");
}
// 요청 처리 로직
}
private boolean isValid(RegisterRequest regReq) {
// 검증 로직 구현
return true; // 실제 검증 로직에 따라 수정
}
}위 코드에서는 ResponseStatusException을 사용하여 상태 코드와 오류 메시지를 설정합니다
. isValid 메서드는 요청 데이터를 검증하는 커스텀 로직을 구현합니다.
5.ResponseEntity로 객체 리턴하고 응답 코드 지정하기
지금까지는 상태 코드를 지정하기 위해 HttpServletResponse의 setStatus(), sendError()를 사용했다. 문제는 HttpServletResponse를 이용해서 404 응답을 하면 JSON 형식이 아닌 서버가 기본으로 제공하는 HTML을 응답 결과로 제공한다는 점이다.
API를 호출하는 입장에서 JSON과 HTML을 모두 처리하는 것은 부담스럽다. 처리에 실패한 경우 HTML 응답 데이터 대신에 JSON 형식의 응답 데이터를 전송해야 API 호출 프로그램이 일관된 방법으로 응답을 처리할 수 있다.
5.1 ResponseEntity를 이용한 응답 데이터 처리
정상인 경우와 비정상인 경우 모두 JSON 응답을 전송하는 방법은 ResponseEntity를 사용하는 것이다.
에러 상황일 때 응답으로 사용할 ErrorResponse 클래스이다.
public class ErrorResponse{
private String message;
public ErrorResponse(String message){
this.message = message;
}
public String getMessage(){
return message;
}
}} ResponseEntity를 사용하면 member() 메서드를 아래와 같이 구현할 수 있다.
@RestController
public class RestMemberController{
...
@GetMapping("/api/members/{id}")
public ResponseEntity<Object> member(@PathVariable Long id){
Member member = memberDao.selectById(id);
if(member==null){
//ErrorResponse를 body로 지정해서,
//ErrorResponse를 JSON으로 변환한다.
return ResponseEntity
.status(HttpStatus.NOT_FOUND)
.body(new ErrorResponse("no member"));
}
//member를 body로 지정해서, member 객체를 JSON으로 변환한다.
return ResponseEntity.status(HttpStatus.OK).body(member);
}
}스프링 MVC는 리턴 타입이 ResponseEntity이면 body로 지정한 객체를 사용해서 변환을 처리한다. ResponseEntity의 status로 지정한 값을 응답 상태 코드로 사용한다.
존재하지 않는 ID를 이용해서 실행한 결과 404 상태 코드와 함께 JSON 형식으로 응답 데이터를 전송한 것을 확인할 수 있다.
ResponseEntity를 생성하는 기본 방법은 status와 body를 이용해서 상태 코드와 JSON으로 변환할 객체를 지정하는 것이다.
ResponseEntity.status(상태코드).body(객체)
200(OK) 응답 코드와 몸체 데이터를 생성할 경우 다음과 같이 ok() 메서드를 이용할 수 있다.
ResponseEntity.ok(member)
만약 몸체 내용이 없다면 다음과 같이 body를 지정하지 않고 build()로 바로 생성한다.
ResponseEntity.status(HttpStatus.NOT_FOUND).build()
몸체 내용이 없는 경우 status() 메서드 대신에 다음과 같이 관련 메서드를 사용해도 된다.
ResponseEntity.notFound().build()
- noContent(): 204
- badRequest(): 400
- notFound(): 404
newMember()에서 201(Created) 상태 코드와 Location 헤더를 함께 전송하는 방법
//1
response.setHeader("Location", "/api/members/"+newMemberId);
response.setStatus(HttpServletResponse.SC_CREATED);
//2
URI uri = URI.create("/api/members/"+newMemberId);
return ResponseEntity.created(uri).build();5.2 @ExceptionHandler 적용 메서드에 ResponseEntity로 응답하기
앞선 코드는 member가 존재하지 않을 때 기본 HTML 에러 응답 대신에 JSON 응답을 제공하기 위해 ResponseEntity를 사용했다.
그런데 회원이 존재하지 않을 때 404 상태 코드를 응답해야 하는 기능이 많으면 에러 응답을 위해 ResponseEntity를 생성하는 코드 중복이 발생한다.
이때 @ExceptionHandler 어노테이션을 적용한 메서드에서 에러 응답을 처리하도록 구현하면 중복을 없앨 수 있다.
@GetMapping("/api/members/{id}")
public ResponseEntity<Object> member(@PathVariable Long id){
Member member = memberDao.selectById(id);
if(member==null){
throw new MemberNotFoundException();
}
return member;
}
@ExceptionHandler(MemberNotFoundException.class)
public ResponseEntity<ErrorResponse> handleNoData(){
return ResponseEntity
.status(HttpStatus.NOT_FOUND)
.body(new ErrorResponse("no member");
}위 코드의 member() 메서드는 Member 자체를 리턴한다.
회원 데이터가 존재하면 Member 객체를 리턴하므로 JSON으로 변환한 결과를 응답한다.
회원 데이터가 존재하지 않으면 MemberNotFoundException을 발생한다.
이 익셉션이 발생하면 @ExceptionHandler 어노테이션을 사용한 handleNoData() 메서드가 에러를 처리한다.
404 상태 코드와 ErrorResponse 객체를 몸체로 갖는 ResponseEntity를 반환한다.
즉, MemberNotFoundException가 발생하면 상태코드가 404이고 몸체가 JSON 형식인 응답을 전송한다.
@RestControllerAdvice 어노테이션을 이용해서 에러 처리 코드를 별도 클래스로 분리할 수도 있다. @RestControllerAdvice는 @ControllerAdvice와 동일하다. 차이는 @RestController와 동일하게 응답을 JSON, XML 형식으로 변환한다는 것이다.
@RestControllerAdvice("controller")
public class ApiExceptionAdvice{
@ExceptionHandler(MemberNotFoundException.class)
public ResponseEntity<ErrorResponse> handleNoData(){
return ResponseEntity
.status(HttpStatus.NOT_FOUND)
.body(new ErrorResponse("no member");
}
}@RestControllerAdvice를 사용하면 에러 처리 코드가 한 곳에 모여 효과적으로 에러 응답을 관리할 수 있다.
5.3 @Valid 에러 결과를 JSON으로 응답하기
@Valid 어노테이션을 붙인 커맨드 객체가 값 검증에 실패하면 400 상태 코드를 응답한다.
@PostMapping("/api/members") public ResponseEntity<Object> newMember(@RequestBody @Valid RegisterRequest regReq){ ... }문제는 HttpServletResponse를 이용해서 상태 코드를 응답했을 때와 마찬가지로 HTML 응답을 전송한다.
@Valid 어노테이션을 이용한 검증을 실패했을 때 HTML 응답 대신 JSON 형식의 응답을 제공하고 싶으면 Errors 타입 파라미터를 추가해서 직접 에러 응답을 생성하면 된다.
@PostMapping("/api/members")
public ResponseEntity<Object> newMember(@RequestBody @Valid RegisterRequest regReq, Errors errors){
if(errors.hasErrors()){
String errorCodes=errors.getAllErrors()//List<ObjectError>
.stream()
.map(error->error.getCodes()[0])//error는 ObjectError
.collect(Collectors.joining(","));
return ResponseEntity
.status(HttpStatus.BAD_REQUEST)
.body(new ErrorResponse("errorCodes="+errorCodes);
}
...
}hasErrors() 메서드를 이용해서 검증 에러가 있는지 확인한다.
검증에러가 존재하면 모든 에러 정보를 구하고 각 에러 코드 값을 연결한 문자열을 생성해서 errorCodes 변수에 할당한다.
이처럼 코드를 수정한 후 검증에 실패하는 데이터를 전송하면 JSON 응답이 오는 것을 확인할 수 있다.
@RequestBody를 붙인 경우 @Valid를 붙인 객체의 검증에 실패했을 때 Errors 타입 파라미터가 존재하지 않으면 MethodArgumentNotValidException이 발생한다.
따라서 다음과 같이 @ExceptionHandler 어노테이션을 이용해서 검증 실패시 에러 응답을 생성해도 된다.
@RestControllerAdvice("controller")
public class ApiExceptionAdvice{
@ExceptionHandler(MethodArgumentNotValidException.class)
public ResponseEntity<ErrorResponse> handleBindException(MethodArgumentNotValidException ex){
String errorCodes=ex.getBindingResult().getAllErrors()
.stream()
.map(error->error.getCodes()[0])
.collect(Collectors.joining(","));
return ResponseEntity
.status(HttpStatus.BAD_REQUEST)
.body(new ErrorResponse("errorCodes="+errorCodes);
}
}Chapter17 프로필과 프로퍼티 파일
1.프로필
프로필(Profile)은 스프링에서 환경별로 설정을 다르게 관리할 수 있도록 해주는 기능입니다.
이를 통해 개발 환경과 실제 서비스 환경의 설정을 분리하여 관리할 수 있으며, 실수를 방지하고 효율적인 개발과 배포를 도와줍니다.
프로필의 개념
프로필은 논리적인 이름으로서 설정 집합에 프로필을 지정할 수 있다. 스프링 컨테이너는 설정 집합 중에서 지정한 이름을 사용하는 프로필을 선택하고 해당 프로필에 속한 설정을 이용해서 컨테이너를 초기화할 수 있다.
프로필 적용의 예시
예를 들어 로컬 개발 환경을 위한 DataSource 설정을 "dev" 프로필로 지정하고 실 서비스를 위한 설정을 "real" 프로필로 지정한 뒤, "dev" 프로필을 이용해서 스프링 컨테이너를 초기화할 수 있다. 그럼 "dev" 프로필에 정의된 빈을 사용하게 된다.
1.1 @Configuration 설정에서 프로필 사용하기
@Configuration 어노테이션을 이용한 설정에서 프로필을 지정하려면 @Profile 어노테이션을 이용한다.
@Configuration
@Profile("dev")
public class DsDevConfig{
@Bean(destroyMethod="close")
public DataSource dataSource(){
...
}
}
@Configuration
@Profile("real")
public class DsRealConfig{
@Bean(destroyMethod="close")
public DataSource dataSource(){
...
}
}스프링 컨테이너를 초기화할 때 "dev" 프로필을 활성화하면 DsDevConfig 클래스를 설정으로 사용한다.
두 dataSource 빈 중에 어떤 빈을 사용할지는 활성화한 프로필에 따라 달라진다. 특정 프로필을 선택하려면 컨테이너를 초기화하기 전에 setActiveProfiles() 메서드를 사용해서 프로필을 설정해야 한다.
context.getEnviroment().setActiveProfiles("dev"); context.register(MemberConfig.class, DsDevConfig.class, DsRealConfig.class); context.refresh();
프로필을 사용할 때 주의할 점은 설정 정보를 전달하기 전에 어떤 프로필을 사용할지 지정해야 한다는 점이다.
dev로 설정 후 register() 메서드로 설정 파일 목록을 지정한다. 이후 refresh() 메서드를 실행해서 컨테이너를 초기화했다.
시스템 프로퍼티를 이용하여 설정할 수도 있다.
java -Dspring.profiles.active=dev main.Main
자바의 시스템 프로퍼티뿐만 아니라 OS의 "spring.profiles.active" 환경 변수에 값을 설정해도 된다. 프로필의 우선순위는 다음과 같다.
- setActiveProfiles()
- 자바 시스템 프로퍼티
- OS 환경 변수
1.2 @Configuration을 이용한 프로필 설정
중첩 클래스를 이용해서 프로필 설정을 한 곳으로 모을 수 있다.
@Configuration
public class MemberConfigWithProfile{
@Autowired
private DataSource dataSource;
@Bean
public MemberDao memberDao(){
return new MemberDao(dataSource);
}
@Profile("dev")
public class DsDevConfig{
@Bean(destroyMethod="close")
public DataSource dataSource(){
...
}
}
@Profile("real")
public class DsRealConfig{
@Bean(destroyMethod="close")
public DataSource dataSource(){
...
}
}
}1.3 다수 프로필 설정
스프링 설정은 두 개 이상의 프로필 이름을 가질 수 있다.
@Configuration @Profile("real,test") public class DataSourceJndiConfig{ ... }프로필을 설정할 때 느낌표를 사용하면 해당 프로필이 활성화되지 않았을 때 사용한다는 것을 의미한다.
보통 "!프로필" 형식은 특정 프로필이 사용되지 않을 때 기본으로 사용할 설정을 지정하는 용도로 사용된다.
2. 프로퍼티 파일을 이용한 프로퍼티 설정
스프링은 외부의 프로퍼티 파일을 이용해서 스프링 빈을 설정하는 방법을 제공하고 있다.
다음과 같은 db.properties 파일이 있다고 하자. 이 파일의 프로퍼티 값을 자바 설정에서 사용할 수 있으며 이를 통해 설정 일부를 외부 프로퍼티 파일을 사용해서 변경할 수 있다.
db.driver=com.mysql.jdbc.Driver db.url=jdbc:mysql://localhost/spring5fs?characterEncoding=utf8 db.user=spring5 db.password=spring5
2.1 @Configuration 어노테이션 이용 자바 설정에서의 프로퍼티 사용
자바 설정에서 프로퍼티 파일을 이용하려면 다음 두 가지를 설정한다.
* PropertySourcesPlaceholderConfigurer 빈 설정
* @Value 어노테이션으로 프로퍼티 값 사용
```java
@Configurationpublic class PropertyConfig{ @Bean public static PropertySourcesPlaceholderConfigurer properties(){ PropertySourcesPlaceholderConfigurer configurer = new PropertySourcesPlaceholderConfigurer(); configurer.setLocations( new ClassPathResource("db.properties"), new ClassPathResource("info.properties"));
return configurer;
}}
setLocations()는 프로퍼티 파일 목록을 인자로 전달받는다. 이때 스프링은 Resource 파입을 이용해서 파일 경로를 전달한다.
위 코드에서 주의할 점은 PropertySourcesPlaceholderConfigurer 타입 빈을 설정하는 메서드가 정적(static)이라는 것이다. 이는 PropertySourcesPlaceholderConfigurer 클래스가 특수한 목적의 빈이기 때문이며 정적 메서드로 지정하지 않으면 원하는 방식으로 동작하지 않는다.
PropertySourcesPlaceholderConfigurer 타입 빈은 setLocation() 메서드로 전달받은 프로퍼티 파일 목록 정보를 읽어와 필요할 때 사용한다. 이를 위한 것이 @Value 어노테이션이다.
```java
@Configuration
public class DsConfigWithProp{
@Value("${db.driver}")
private String driver;
...
}@Value 어노테이션이 ${구분자} 형식의 플레이스홀더 값으로 갖고 있다. ${db.driver} 플레이스홀더 값을 db.properties에 "db.driver" 프로퍼티 값으로 치환한다.
따라서 실제 빈을 생성하는 메서드는 @Value 어노테이션이 붙은 필드를 통해서 해당 프로퍼티의 값을 사용할 수 있다.
2.2 빈 클래스에서 사용하기
빈으로 사용할 클래스에도 @Value 어노테이션을 붙일 수 있다.
@Value 어노테이션을 필드에 붙이면 플레이스홀더에 해당하는 프로퍼티를 필드에 할당한다.
public class Info{
@Value("${info.version}")
private String version
...
}다음과 같이 @Value 어노테이션을 set 메서드에 적용할 수도 있다
public class Info{
private String version;
...
@Value("${info.version}")
public void setVersion(String version){
this.version=version;
}
}
hongsujin2eeZyo
haewonee
DispatcherServlet은 모든 연결을 담당한다.
웹 브라우저로부터 요청이 들어오면 DispatcherServlet은 그 요청을 처리하기 위한 컨트롤러 객체를 검색하는데,
이때 DispatcherServlet은 직접 컨트롤러를 검색하지 않고 HandlerMapping이라는 빈 객체에게 컨트롤러 검색을 요청한다.
HandlerMapping은 클라이언트의 요청 경로를 이용해서 이를 처리할 컨트롤러 빈 객체를 DispatcherServlet에 전달한다. 
DispatcherServlet은 HandlerMapping이 찾아준 컨트롤러 객체를 처리할 수 있는 HandlerAdapter 빈에게 요청 처리를 위임한다.
HandlerAdapter는 컨트롤러의 알맞은 메서드를 호출해서 요청을 처리하고 그 결과를 DispatcherServlet에 리턴하는데, 이때 컨트롤러의 처리 결과를 ModelAndView라는 객체로 변환해서 DispatcherServlet에 리턴한다.
HandlerAdapter로부터 컨트롤러의 요청 처리 결과를 ModelAndView로 받으면 DispatcherServlet은 결과를 보여줄 뷰를 찾기 위해 ViewResolver 빈 객체를 사용한다.
ModelAndView는 컨트롤러가 리턴한 뷰(논리적 뷰) 이름을 담고 있는데 ViewResolver는 이 논리적 뷰 이름을 실제 뷰(JSP파일)로 변환한다. 이 과정에서 새로운 View 객체가 생성된다. 이를 DispatcherServlet에 리턴한다.
DispatcherServlet은 생성된 View 객체를 사용하여 JSP를 렌더링하고, 결과를 클라이언트에게 응답으로 반환한다.
DispatcherServlet은 전달받은 설정 파일을 이용해 스프링 컨테이너를 생성하고 그 컨테이너로부터 필요한 빈 객체를 구한다.
따라서 DispatcherServlet이 사용하는 설정 파일에 이들 빈에 대한 정의가 포함되어 있어야 한다.
왼쪽 코드는 각 요청 매핑 애노테이션의 경로가 "/haewon"으로 시작하는데, 이렇게 메서드마다 중복되는 경로를 쓰지 않고 오른쪽 코드처럼 수정할 수 있다.
공통되는 부분의 경로를 담은 @RequestMapping 애노테이션을 클래스에 적용하고 각 메서드는 나머지 경로를 값으로 갖는 요청 매핑 애노테이션을 적용하는 것이다.
taekyun0219
스프링 프로그래밍 입문 5 남은 부분 정독