1. 보다 나은
웹 애플리케이션 설계
@EBvi

2. 이 문서는 spring과 myBatis를
처음 도입하는 팀을 위해 작성
되었습니다

3. spring을 선택해야 하는 이유

4. 왜 spring을 써야 합니까?

5. 결코 쉽지 않은 질문입니다만

6. 차근차근 이유를 알아가보도록
합시다

7. 우선 별로 spring과 관계없는
것부터 시작해보죠

8. 우리가 그동안 작성해왔던
소스코드

10. 입력값 검증

11. 서버단에서 사용자에게
에러를 보여줘야할 의무가
있습니까?

12. 보여줄 필요가 있는 것만 구현

14. 그렇다면 반드시 필요한
파라메터는 어떻게 검증?

15. @RequestParam
spring에서는 이렇게 간단하게 지정

16. 파라메터가 들어오지 않으면
아예 접근되지 않음

17. 그래도 사용자에게 알려줘야
하지 않을까요?

18. jQuery로 간단하게 해결

20. alt 속성을 가진
input 태그만을 검증

22. 필드가 삭제되거나 늘어나도
검증부를 수정할 필요가
전혀 없습니다

24. 기존소스는 필드가 변경되면
javascript 오류가
날 수 있었죠

25. 위험요소를 원천적으로 차단하
는 것이 좋은 설계입니다

26. 이 원칙은 대단히 중요합니다

27. Expression Language

28. 왜 EL 태그를 써야 할까요?

29. 웹 티어에 비지니스 로직이
절대로 존재해서는 안된다

31. 사실 이정도는
비지니스 로직이 포함되었다고
보기 어렵습니다만

32. 모 회사 모 프로젝트의 소스

34. 중간중간 로직은 물론
데이터베이스까지 접근하고
있는 악질코드입니다

35. 이런 소스코드의 디자인을
수정하라고 하면
그냥 새로 만드는 게 더 쉽습니다

36. 로직 없이
EL만 들어간 깔끔한 코드

38. 로직이 비지니스단에만
존재하게 되면 프리젠테이션의
변경이 매우 쉬워집니다

39. 어쩔 수 없는 특별한 상황을
제외하고 비지니스 로직은
비지니스단에만 구현합시다

40. Duplicate code

41. 중복된 코드는 쓸데없는 데다
가 코드를 확장, 유지하기 어렵
게 만드는 주범입니다

42. 등록폼과 수정폼을 나눠서 만들었었죠
이 소스간의 차이는 그리 크지 않습니다

43. 그렇다면 하나로 합치면 안될
까요?

44. jsp에서는 attribute에 담겼는
지 아닌지만 알면 됩니다

45. 담겨있지 않으면 등록
담겨있으면 수정

46. 해당 객체가 null일 경우 그냥 출력되지 않습니다

47. action의 주소도 조건에 따라
가리키게 만듭시다

48. 단 EL에서는 IF ELSE가 없기 때문에 choose를 사용
할 수 밖에 없습니다
사실 FN을 정의해서 만들면 되지만 이건 나중에

49. 아참! 이거 중요합니다
폼의 submit을 제어할 땐 이렇게 구현하세요

50. 이전 소스
그동안은 이미지가 클릭될 때 submit되는
javascript 함수를 구현했었죠

51. 이렇게 만들면 다양한 문제가
발생합니다

52. 그중에서도 특히 사용성, 접근
성이 크게 떨어지게 됩니다

53. input[type=image]로 구현

54. 서버에서 검증할 거니까 잘못
등록될 수 없습니다

55. javascript를 오용하고 있는
대표적인 사례입니다

56. Dispatcher Servlet

57. spring은 기본적으로
모든 서블릿을 가로채 가도록
설정합니다

58. web.xml에 설정

59. 이렇게 하면 나머지 동작은
spring이 모두 보증합니다

60. 보증한다는 의미는 더이상 여
러분이 신경쓰지 않아도 된다
는 의미입니다

61. UTF-8에서 한글처리는
filter를 사용

62. 이렇게 설정해도 get으로 보낼
때 한글이 깨지는 경우가 생길
수 있습니다

63. 그 경우는 server.xml의
charset을 utf-8로 변경하면 됩
니다

64. 이제 web.xml에
applicationContext 주소를
잡아주기만 하면 설정이 끝납니다

65. Application Context

67. 다양한 설정을 하는
xml 형태의 파일입니다만

68. 여기에서 bean을 선언하면
서블릿을 가로챌 때 spring이
bean을 주입시킵니다

69. 이제 매 서비스마다 new를
쓸 필요가 없습니다

70. 객체를 생성하고 주입하는 걸
spring이 모두 보증합니다

72. 왜 new를 선언하지 않는
설계가 좋은 설계일까요?

73. 왜냐하면

74. new를 선언하는 순간

75. 인스턴스를 생성하게 되고

76. 해당 클래스는

77. 반드시 인스턴스에 해당하는
클래스를 알아야 하게 됩니다

78. 즉, 의존성이 생겨나게 됩니다

79. 의존성이 생겨나는 것은
왜 문제가 될까요?
그냥 new하면 안되나요?

80. == 예제 코드 시현 ==

81. 물론 interface도 해당
interface에 대한 의존성이 생
기는 것입니다

82. 그러나 직접 구현한 클래스를
아는 것과 구상을 가리키는 것
은 큰 차이가 있습니다

83. @Controller

84. 먼저 spring에게 컨트롤러
위치를 알려줍시다

85. spring은 web.xml에 지정한
{name}-servlet.xml을
참조합니다
springapp으로 지정했으니까
springapp-servlet.xml을 찾습니다

86. {name}-servlet.xml

87. 이렇게 알려주면 spring이
여기서 컨트롤러를
찾게 됩니다

88. @Controller

89. @Controller로 선언된 클래
스의 메서드는 각각의 action
으로 정의할 수 있습니다

90. 이전의 방식
각각의 ACTION을 관리하고
IF ELSE(또는 SWITCH)로
찾느라 복잡했었죠

91. 이제 action resolver를
구현할 필요가 없습니다

92. 이렇게 구현하면 여러분은
url만 보고 바로 검색해서
액션을 찾을 수 있게 됩니다

93. View Resolver

94. view resolver를 사용하면 컨트
롤러에서 jsp 파일을 리턴할 때
좀 더 편리하게 쓸 수 있습니다

95. 이런식으로 뷰를 알려주죠

96. 우선 물리적인 파일을 사용자
에게 노출시키지 않기 위해

97. 모든 jsp 파일을 /WEB-INF/jsp
로 이동시킵시다

98. WEB-INF에 들어있는 파일은
외부에서 절대 접근할 수 없기
때문에

99. 이렇게 만드는 것이 훨씬 안전
합니다

100. 외부에 노출되어서는 안되는
관리자 모드의 jsp 파일을 보여
줘선 안되겠죠?

101. 그런데 이렇게 만들고 나니

102. 매번 /WEB-INF/jsp/...와 같은
경로를 써줘야 하는 번거로움
이 생깁니다

103. {name}-servlet.xml
이렇게 뷰 리졸버를 정의해서 prefix
와 postfix를 알려줄 수 있습니다

104. 이렇게 하면 경로를 다시 쓸 필
요없이 /WEB-INF/jsp/의 경로
를 가리키게 됩니다

105. RESTful

106. REST하지 않은 자원들

107. 이러한 주소는 자원으로써
의미가 전혀 없습니다

108. 개발자 입장에서도 통일성이
없기 때문에 중구난방으로
생성되고 관리되게 됩니다

109. 좋다고 해도 REST한 주소를
만들기란 꽤 어려웠습니다
바보라서 안만든게 아니라 만드느라 복잡성이 더 증가했기 때문이죠

110. 하지만

111. @RequestMapping을 사용해서
정말 손쉽게 만들어낼 수 있습니다

112. 직관적이고 통일성있는
URL은 모두에게 좋습니다

113. Value Object Pattern

114. VO가 DTO와 어떤 차이가 있는 지에 대해
선 조금 논의가 분분합니다. 이 문서엔 Core
j2ee patterns를 따라 VO를 DTO와 동일한
패턴으로 정의합니다

115. 이전 방식

116. HashMap에 일일히 담고
검증하고 초기화했었습니다

117. 만약 parameter가 변경된다면
컨트롤러를 따라가며
전부 수정해야 할 겁니다

118. 추가-삭제가 빈번하게 일어난다면
HashMap에 담긴 자원이 유효하
다는 걸 어떻게 보증하실 건가요?

119. HashMap은 편리하지만
보증할 수가 없습니다

120. 위험한 일은 아예 일어나지 않
도록 원천적으로 차단합시다

121. private로 된 필드를 만듭시다

122. 자동으로 get-set 메소드를
만들어 줍시다

124. 이러면 get-set 메서드가 자동으로
생성됩니다

125. 이렇게 만들면
spring이 매핑할 때
get-set 메서드를 지나갑니다

126. get-set 메소드를 만드는 것은
필수적입니다

127. 만들지 않으면 주입할 수 있는
방법이 없습니다

128. 만약 좀 더 제약을 걸고 싶으면
get-set 메서드에서
해당 사항을 구현하면 됩니다

129. 이러면 절대 null이 리턴되지
않고 xss에도 안전해지겠죠?

130. 지금까지 오면서
여러분이 느끼셨는지
모르겠습니다만

131. 제약을 건다는 건
좀 더 단순해진다는 걸
의미합니다

132. 반드시
이렇게 만들어질 수 밖에 없다

133. 반드시
이것을 통과할 수 밖에 없다

134. 반드시
유일한 값이 들어가야만 한다

135. 반드시
로직이 존재해서는 안된다

136. 반드시

137. ...

138. 이러한 제약은
문제를 좀 더 단순하게 만드는
좋은 설계의 원칙이 됩니다

139. 예외가 생기면
문제가 복잡해집니다

140. 우리는 그 예외까지도
단순하게 설계해야 합니다

141. 꼭 기억해주세요

142. 아참, 이와 같은 객체를 POJO
라고 부르고 이와 같은 패턴을
VO라고 부릅니다

143. POJO는 특정 기능, 프레임워
크에 종속되지 않은 순수한 객
체를 말합니다

144. 특정 구현을 상속 받거나 의존
성이 있는 것도 아니고 그냥 아
무 것도 없죠

145. Data Access Object Pattern

146. 마찬가지의 개념입니다

147. persistence단에서
비지니스 로직은 절대 있어서
안됩니다

148. 오직 데이터베이스와 관련된
행동만 보여주도록 만듭시다

149. 이것을 객체지향 설계에서

150. 단일책임 원칙(single
responsibility principle)이라
고 합니다

151. 객체가 단 한 개의 책임만을 가
져야 한다는 설계 원칙입니다

153. 이게 전부입니다

154. 우리는 return type과
parameter type만 알면

155. 나머지는 전혀 신경 쓸 필요가
없습니다

156. 그렇기 때문에 구현된 클래스가
아닌 인터페이스만 봐도 뭘 어떻
게 구현했는지 알 수 있습니다

157. 한 6개월 정도 지나서 모든 기
억이 가물거리기 시작하면

158. 이것만 봐도 DAO가 어떻게 구
현됐는지 쉽게 떠올릴 수 있죠

159. 그러면 이제 직접 쿼리를 수정
하러 가 봅시다

160. applicationContext.xml
myBatis와 관련된 설정은
이 지점에서만 확인하면 OK

161. sqlmap-config.xml
여긴 각종 별칭(alias)을 정의해
편리하게 갖다 쓸 수 있음

162. 별칭을 정하지 않으면 매번
package를 다 써줘야 하니 정
해서 편리하게 이용합시다

163. *.xml

164. 각각 분리해서 관리하는 것이
편리합니다

165. 하나의 xml에서 모두 관리하게
되면 코드가 길어지고 검색하
기도 불편하겠죠

166. 다만 중요한 원칙은 물리적인
데이터베이스 모델링에 맞추는
것이 아니라

167. 논리적인 데이터베이스 모델링
에 맞춰 나누는 것입니다

168. 이러한 점은 VO 설계에도 마찬
가지입니다

169. VO의 필드를 물리적인 데이터
베이스 필드와 동일하게 맞추
지 마세요

170. 컴퓨터는 기계지만 여러분은
사람입니다

171. 컴퓨터가 융통성이 없다면 여
러분이 융통성 있게 코드를 작
성하면 됩니다

172. 물론 반드시 다르게 만들라는
말은 아닙니다

173. 어째튼 데이터베이스의 필드명
과 VO의 필드명이 다르므로

174. alias를 사용해서 매퍼에게 알
려줘야 합니다

175. AS로 각각의 필드에 별칭을
만들어주세요

176. alias로 만든 이름과 vo의 이름
이 같으면 myBatis가 set 메서
드로 넣어서 리턴해줍니다

177. 또한
myBatis는 강력한 기능을 많이
가지고 있는데

178. dynamic query를 작성하기에
도 매우 편리합니다

179. 사실 대부분의 검색 조건은 파라
메터가 있냐없냐 이거죠

180. myBatis는 data type을 반드시
알려줘야 하기 때문에

181. 만약 처음 도입하게 된다면

182. parameter type과 return
type 때문에 고생할 수도 있습
니다

183. 매퍼와 관련해서 오류가 나는
것은 data type이 달라서 그렇
습니다

184. 정리

185. 소스 코드를
중복하여 작성하지 말라

186. 위험요소는
원천적으로 차단하라

187. 로직은 반드시 존재해야 하는
곳에만 존재해야 한다

188. 한 객체에 하나의 책임을 갖도
록 설계하라

189. 특정 구현이 아닌 인터페이스
에 맞춰 프로그래밍하라

190. 후라이드 반 양념 반

191. Reference from
• One on one J2EE design and • Professional software
development development
• Kent’s beck implementation • Java Development with the
patterns Spring Framework
• The practice of programming • Spring in action
• The psychology of computer • Core J2EE patterns
programming

192. 고맙습니다