[MVC 구현하기 - 2단계] 오잉(이하늘) 미션 제출합니다. #491
Conversation
…onHandler도 처리할 수 있도록 로직 수정
hanueleee
changed the title
| Enumeration<String> attributeNames = request.getAttributeNames(); | ||
| while (attributeNames.hasMoreElements()) { | ||
| String attributeName = attributeNames.nextElement(); | ||
| Object attributeValue = request.getAttribute(attributeName); | ||
| modelAndView.addObject(attributeName, attributeValue); | ||
| } |
There was a problem hiding this comment.
해당 부분을 통해 request에서 attribute를 가져온 뒤, Model을 설정해주고 JspView에서 다시 Model에서 가져온 값을 request.setAttribute로 설정해주는 것 같아요.
그렇다면 request의 Attribute는 언제 사용되는건지 궁금해요. parameter와는 어떤 차이가 있나요?
There was a problem hiding this comment.
Sevlet의 HttpServletRequest는 attribute를 통해 임시 저장소 기능을 제공합니다.
ManualHandlerAdapter에서 사용되는 Controller의 경우에는 request를 이용해 로직을 수행하고 response를 세팅해준 후
적절한 viewName을 반환합니다.
이 때 Controller안에서 View로 뭔가의 데이터를 넘기기 위해서는
request의 attribute를 사용해 데이터를 담아야 한다고 생각했습니다.
그래서 해당 로직을 통해 request에서 attribute를 꺼내 model로 옮겨주는 작업을 했습니다.
There was a problem hiding this comment.
그렇다면 request의 Attribute는 언제 사용되는건지 궁금해요. parameter와는 어떤 차이가 있나요?
Parameter
- 클라이언트에서 서버로 데이터를 전달하는 데 사용
- 주로 URL 쿼리 문자열 또는 HTML 폼 요청의 매개변수로 전송
Attribute
- 웹 애플리케이션의 다른 부분 간에 데이터를 공유하는 데 사용
- 주로 서블릿, JSP 페이지 및 다른 웹 구성 요소 간에 데이터를 전달하는 데 사용
There was a problem hiding this comment.
깔끔한 설명 굿입니다 ㅎㅎ 👍👍
저도 리뷰하면서 처음 알았는데 덕분에 배워갑니다!
레거시 컨트롤러는 String 문자열만 반환하기 때문에 Model 객체를 전달할 수 없는데 이렇게 Request의 Attribute를 사용하면 쉽게 데이터를 전달할 수 있겠네요~!
mvc/src/main/java/webmvc/org/springframework/web/servlet/mvc/AnnotationHandlerAdapter.java
Outdated
Show resolved
Hide resolved
mvc/src/main/java/webmvc/org/springframework/web/servlet/mvc/AnnotationHandlerMapping.java
Outdated
Show resolved
Hide resolved
|
안녕하세요 오잉 코드 잘 작성해주셨어요! 깔끔해서 읽기 좋았습니다 🙂 궁금한 부분이나 변경되어야 할 부분에 대해서는 코멘트 남겨드렸고, 이 코멘트에서 본문에서 질문주신 내용에 대해 답해보고자 합니다.
사실 멀티모듈에 대해 정확히 아는 건 아니라 확답을 드리긴 어려운데요, 개인적인 의견을 우선 제시하도록 하겠습니다! 저는 개인적으로 현재 MVC 단에는 프레임워크 영역의 클래스들이 위치하면 좋을 것 같아요. 사실 DispatcherServlet은 Servlet Container의 관리 대상이기 때문에 MVC 모듈에 위치하는게 괜찮지 않나는 생각이 듭니다. Controller의 구현체는 실제 비즈니스 로직을 작성할 대상이므로 App에 위치하는게 맞다는 생각도 듭니다. 다만 ManualHandlerMapping, ManualHandlerAdapter의 경우에는 mvc에 위치하는게 맞지 않을까요? 스프링이라는 프레임워크의 존재 이유 자체가 POJO 스타일의 객체지향 설계를 가능하게 하기 위함인데, app 모듈에서 프레임워크와 관련된 코드를 다룰 필요는 없을 것 같아요.
오잉은 어떤 기준으로 예외를 전환하시는지 궁금해요. 예외를 전환하면 어떤 이점이 있을까요? 저는 개인적으로 예외를 전환하는 경우는 1. 비즈니스적으로 의미가 있는 예외로 전환하거나, 2. 계층 간의 격리를 지키기 위해 예외를 전환하거나, 3. Checked Exception을 Unchecked Exception으로 전환하는 경우에만 사용하거든요. init에서 예외가 발생했다는 것은 어플리케이션의 코드 구조에 문제가 있음을 의미하는 것이니까, 굳이 전환을 시키거나 catch를 할 필요는 없다고 생각해요. 결국 예외 객체가 존재하는 이유는 '예외 상황의 문맥을 전달하기 위함'인데, 해당 목적만 충실히 이행한다면 굳이 전환을 해줄 필요는 없을 것 같다는 생각입니다! |
|
안녕하세요 테오!
말씀해주신대로 저도 이번 미션은 ‘스프링 mvc 구현하기’이기 때문에 mvc 모듈 상에 프레임워크 영역의 모든 클래스들이 위치하는 것이 좋다고 생각합니다! 그래서 우선 app에 위치하던 manualHandlerAdapter와 controller 인터페이스를 mvc로 이동시켰는데요, 위 두 클래스를 옮기기 위해서는 인터페이스라던가 리플렉션?등을 이용해 의존성 역전을 시켜봐야할 것 같아서 시간이 좀 걸릴 것 같습니다..🤣
역시 교수님.. 저는 지금까지 그저 기계적으로 많이 배웠습니다. 감사합니다…🙇♀️ |
안녕하세요 테오!
2단계 미션이 조금 늦었네요 🤣
이번 단계에서는 요구사항대로
컨트롤러 인터페이스 기반 MVC 프레임워크와어노테이션 기반 MVC 프레임워크를 공존하도록 했습니다.이를 위해 ManualHandlerMapping과 AnnotationHandlerMapping을 HandlerMapping으로 추상화하고,
각각을 처리할 수 있는 HandlerAdapter를 만들었습니다.
흐름은 다음과 같습니다.
미션을 진행하며 몇가지 고민이 있었는데요.. 교수님의 생각이 궁금합니다!!
멀티모듈에서의 패키지 관리
제공받은 뼈대코드는 mvc모듈(프레임워크), app모듈(서비스영역)으로 나뉘어져있습니다.
그러다보니 각 클래스를 어떤식으로 두는게 좋을지 모르겠습니다..
현재 저는 app모듈에 dispatcherServlet과 manualHandlerMapping, manualHandlerAdapter, controller 인터페이스 구현체들을 두고,
mvc모듈에 handlerMapping인터페이스, handlerAdapter인터페이스, annotationlHandlerMapping, annotationHandlerAdapter이 있습니다.
이 구조에 대해 어떻게 생각하시나요?!
예외처리
저번 리뷰에서 남겨주신 내용에 동의해서
리플렉션을 사용하는 부분(예외가 발생할 수 있는 지점)에서 try-catch로 감싸주도록 코드를 수정했는데 (AnnotationHandlerMapping의 getInstance)
현재 로직에서는 예외가 발생했을 경우 IllegalArgumentException이 쭉쭉 타고 올라가 DispatcherServlet의 init까지 도달할 것 같은데,
해당 부분에 대해 어떻게 생각하시나요.. init에서도 try-catch로 잡아서 ServletException으로 전환하는게 좋을까요?!
잘 부탁드립니다 👨🎤