Your SlideShare is downloading. ×
0
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

보다 나은 웹 어플리케이션 설계

2,036

Published on

Published in: Technology
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,036
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
53
Comments
0
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. 보다 나은웹 애플리케이션 설계 @EBvi
  • 2. 이 문서는 spring과 myBatis를처음 도입하는 팀을 위해 작성 되었습니다
  • 3. spring을 선택해야 하는 이유
  • 4. 왜 spring을 써야 합니까?
  • 5. 결코 쉽지 않은 질문입니다만
  • 6. 차근차근 이유를 알아가보도록 합시다
  • 7. 우선 별로 spring과 관계없는 것부터 시작해보죠
  • 8. 우리가 그동안 작성해왔던 소스코드
  • 9. 입력값 검증
  • 10. 서버단에서 사용자에게에러를 보여줘야할 의무가 있습니까?
  • 11. 보여줄 필요가 있는 것만 구현
  • 12. 그렇다면 반드시 필요한파라메터는 어떻게 검증?
  • 13. @RequestParam spring에서는 이렇게 간단하게 지정
  • 14. 파라메터가 들어오지 않으면 아예 접근되지 않음
  • 15. 그래도 사용자에게 알려줘야 하지 않을까요?
  • 16. jQuery로 간단하게 해결
  • 17. alt 속성을 가진input 태그만을 검증
  • 18. 필드가 삭제되거나 늘어나도 검증부를 수정할 필요가 전혀 없습니다
  • 19. 기존소스는 필드가 변경되면 javascript 오류가 날 수 있었죠
  • 20. 위험요소를 원천적으로 차단하 는 것이 좋은 설계입니다
  • 21. 이 원칙은 대단히 중요합니다
  • 22. Expression Language
  • 23. 왜 EL 태그를 써야 할까요?
  • 24. 웹 티어에 비지니스 로직이절대로 존재해서는 안된다
  • 25. 사실 이정도는비지니스 로직이 포함되었다고 보기 어렵습니다만
  • 26. 모 회사 모 프로젝트의 소스
  • 27. 중간중간 로직은 물론데이터베이스까지 접근하고 있는 악질코드입니다
  • 28. 이런 소스코드의 디자인을 수정하라고 하면그냥 새로 만드는 게 더 쉽습니다
  • 29. 로직 없이EL만 들어간 깔끔한 코드
  • 30. 로직이 비지니스단에만존재하게 되면 프리젠테이션의 변경이 매우 쉬워집니다
  • 31. 어쩔 수 없는 특별한 상황을제외하고 비지니스 로직은비지니스단에만 구현합시다
  • 32. Duplicate code
  • 33. 중복된 코드는 쓸데없는 데다가 코드를 확장, 유지하기 어렵 게 만드는 주범입니다
  • 34. 등록폼과 수정폼을 나눠서 만들었었죠이 소스간의 차이는 그리 크지 않습니다
  • 35. 그렇다면 하나로 합치면 안될 까요?
  • 36. jsp에서는 attribute에 담겼는 지 아닌지만 알면 됩니다
  • 37. 담겨있지 않으면 등록 담겨있으면 수정
  • 38. 해당 객체가 null일 경우 그냥 출력되지 않습니다
  • 39. action의 주소도 조건에 따라 가리키게 만듭시다
  • 40. 단 EL에서는 IF ELSE가 없기 때문에 choose를 사용 할 수 밖에 없습니다 사실 FN을 정의해서 만들면 되지만 이건 나중에
  • 41. 아참! 이거 중요합니다폼의 submit을 제어할 땐 이렇게 구현하세요
  • 42. 이전 소스그동안은 이미지가 클릭될 때 submit되는 javascript 함수를 구현했었죠
  • 43. 이렇게 만들면 다양한 문제가 발생합니다
  • 44. 그중에서도 특히 사용성, 접근 성이 크게 떨어지게 됩니다
  • 45. input[type=image]로 구현
  • 46. 서버에서 검증할 거니까 잘못 등록될 수 없습니다
  • 47. javascript를 오용하고 있는 대표적인 사례입니다
  • 48. Dispatcher Servlet
  • 49. spring은 기본적으로모든 서블릿을 가로채 가도록 설정합니다
  • 50. web.xml에 설정
  • 51. 이렇게 하면 나머지 동작은spring이 모두 보증합니다
  • 52. 보증한다는 의미는 더이상 여러분이 신경쓰지 않아도 된다 는 의미입니다
  • 53. UTF-8에서 한글처리는 filter를 사용
  • 54. 이렇게 설정해도 get으로 보낼때 한글이 깨지는 경우가 생길 수 있습니다
  • 55. 그 경우는 server.xml의charset을 utf-8로 변경하면 됩 니다
  • 56. 이제 web.xml에 applicationContext 주소를잡아주기만 하면 설정이 끝납니다
  • 57. Application Context
  • 58. 다양한 설정을 하는xml 형태의 파일입니다만
  • 59. 여기에서 bean을 선언하면서블릿을 가로챌 때 spring이 bean을 주입시킵니다
  • 60. 이제 매 서비스마다 new를 쓸 필요가 없습니다
  • 61. 객체를 생성하고 주입하는 걸 spring이 모두 보증합니다
  • 62. 왜 new를 선언하지 않는설계가 좋은 설계일까요?
  • 63. 왜냐하면
  • 64. new를 선언하는 순간
  • 65. 인스턴스를 생성하게 되고
  • 66. 해당 클래스는
  • 67. 반드시 인스턴스에 해당하는클래스를 알아야 하게 됩니다
  • 68. 즉, 의존성이 생겨나게 됩니다
  • 69. 의존성이 생겨나는 것은 왜 문제가 될까요?그냥 new하면 안되나요?
  • 70. == 예제 코드 시현 ==
  • 71. 물론 interface도 해당interface에 대한 의존성이 생 기는 것입니다
  • 72. 그러나 직접 구현한 클래스를아는 것과 구상을 가리키는 것 은 큰 차이가 있습니다
  • 73. @Controller
  • 74. 먼저 spring에게 컨트롤러 위치를 알려줍시다
  • 75. spring은 web.xml에 지정한 {name}-servlet.xml을 참조합니다 springapp으로 지정했으니까 springapp-servlet.xml을 찾습니다
  • 76. {name}-servlet.xml
  • 77. 이렇게 알려주면 spring이 여기서 컨트롤러를 찾게 됩니다
  • 78. @Controller
  • 79. @Controller로 선언된 클래스의 메서드는 각각의 action 으로 정의할 수 있습니다
  • 80. 이전의 방식 각각의 ACTION을 관리하고 IF ELSE(또는 SWITCH)로 찾느라 복잡했었죠
  • 81. 이제 action resolver를구현할 필요가 없습니다
  • 82. 이렇게 구현하면 여러분은 url만 보고 바로 검색해서액션을 찾을 수 있게 됩니다
  • 83. View Resolver
  • 84. view resolver를 사용하면 컨트롤러에서 jsp 파일을 리턴할 때좀 더 편리하게 쓸 수 있습니다
  • 85. 이런식으로 뷰를 알려주죠
  • 86. 우선 물리적인 파일을 사용자 에게 노출시키지 않기 위해
  • 87. 모든 jsp 파일을 /WEB-INF/jsp 로 이동시킵시다
  • 88. WEB-INF에 들어있는 파일은외부에서 절대 접근할 수 없기 때문에
  • 89. 이렇게 만드는 것이 훨씬 안전 합니다
  • 90. 외부에 노출되어서는 안되는관리자 모드의 jsp 파일을 보여 줘선 안되겠죠?
  • 91. 그런데 이렇게 만들고 나니
  • 92. 매번 /WEB-INF/jsp/...와 같은경로를 써줘야 하는 번거로움 이 생깁니다
  • 93. {name}-servlet.xml 이렇게 뷰 리졸버를 정의해서 prefix 와 postfix를 알려줄 수 있습니다
  • 94. 이렇게 하면 경로를 다시 쓸 필요없이 /WEB-INF/jsp/의 경로 를 가리키게 됩니다
  • 95. RESTful
  • 96. REST하지 않은 자원들
  • 97. 이러한 주소는 자원으로써 의미가 전혀 없습니다
  • 98. 개발자 입장에서도 통일성이 없기 때문에 중구난방으로 생성되고 관리되게 됩니다
  • 99. 좋다고 해도 REST한 주소를 만들기란 꽤 어려웠습니다바보라서 안만든게 아니라 만드느라 복잡성이 더 증가했기 때문이죠
  • 100. 하지만
  • 101. @RequestMapping을 사용해서정말 손쉽게 만들어낼 수 있습니다
  • 102. 직관적이고 통일성있는URL은 모두에게 좋습니다
  • 103. Value Object Pattern
  • 104. VO가 DTO와 어떤 차이가 있는 지에 대해선 조금 논의가 분분합니다. 이 문서엔 Corej2ee patterns를 따라 VO를 DTO와 동일한 패턴으로 정의합니다
  • 105. 이전 방식
  • 106. HashMap에 일일히 담고검증하고 초기화했었습니다
  • 107. 만약 parameter가 변경된다면 컨트롤러를 따라가며 전부 수정해야 할 겁니다
  • 108. 추가-삭제가 빈번하게 일어난다면HashMap에 담긴 자원이 유효하다는 걸 어떻게 보증하실 건가요?
  • 109. HashMap은 편리하지만 보증할 수가 없습니다
  • 110. 위험한 일은 아예 일어나지 않도록 원천적으로 차단합시다
  • 111. private로 된 필드를 만듭시다
  • 112. 자동으로 get-set 메소드를 만들어 줍시다
  • 113. 이러면 get-set 메서드가 자동으로 생성됩니다
  • 114. 이렇게 만들면 spring이 매핑할 때get-set 메서드를 지나갑니다
  • 115. get-set 메소드를 만드는 것은 필수적입니다
  • 116. 만들지 않으면 주입할 수 있는 방법이 없습니다
  • 117. 만약 좀 더 제약을 걸고 싶으면 get-set 메서드에서해당 사항을 구현하면 됩니다
  • 118. 이러면 절대 null이 리턴되지않고 xss에도 안전해지겠죠?
  • 119. 지금까지 오면서여러분이 느끼셨는지 모르겠습니다만
  • 120. 제약을 건다는 건좀 더 단순해진다는 걸 의미합니다
  • 121. 반드시이렇게 만들어질 수 밖에 없다
  • 122. 반드시이것을 통과할 수 밖에 없다
  • 123. 반드시유일한 값이 들어가야만 한다
  • 124. 반드시로직이 존재해서는 안된다
  • 125. 반드시
  • 126. ...
  • 127. 이러한 제약은문제를 좀 더 단순하게 만드는 좋은 설계의 원칙이 됩니다
  • 128. 예외가 생기면문제가 복잡해집니다
  • 129. 우리는 그 예외까지도단순하게 설계해야 합니다
  • 130. 꼭 기억해주세요
  • 131. 아참, 이와 같은 객체를 POJO라고 부르고 이와 같은 패턴을 VO라고 부릅니다
  • 132. POJO는 특정 기능, 프레임워크에 종속되지 않은 순수한 객 체를 말합니다
  • 133. 특정 구현을 상속 받거나 의존성이 있는 것도 아니고 그냥 아 무 것도 없죠
  • 134. Data Access Object Pattern
  • 135. 마찬가지의 개념입니다
  • 136. persistence단에서비지니스 로직은 절대 있어서 안됩니다
  • 137. 오직 데이터베이스와 관련된행동만 보여주도록 만듭시다
  • 138. 이것을 객체지향 설계에서
  • 139. 단일책임 원칙(singleresponsibility principle)이라 고 합니다
  • 140. 객체가 단 한 개의 책임만을 가져야 한다는 설계 원칙입니다
  • 141. 이게 전부입니다
  • 142. 우리는 return type과parameter type만 알면
  • 143. 나머지는 전혀 신경 쓸 필요가 없습니다
  • 144. 그렇기 때문에 구현된 클래스가아닌 인터페이스만 봐도 뭘 어떻게 구현했는지 알 수 있습니다
  • 145. 한 6개월 정도 지나서 모든 기 억이 가물거리기 시작하면
  • 146. 이것만 봐도 DAO가 어떻게 구현됐는지 쉽게 떠올릴 수 있죠
  • 147. 그러면 이제 직접 쿼리를 수정 하러 가 봅시다
  • 148. applicationContext.xml myBatis와 관련된 설정은 이 지점에서만 확인하면 OK
  • 149. sqlmap-config.xml 여긴 각종 별칭(alias)을 정의해 편리하게 갖다 쓸 수 있음
  • 150. 별칭을 정하지 않으면 매번package를 다 써줘야 하니 정 해서 편리하게 이용합시다
  • 151. *.xml
  • 152. 각각 분리해서 관리하는 것이 편리합니다
  • 153. 하나의 xml에서 모두 관리하게되면 코드가 길어지고 검색하 기도 불편하겠죠
  • 154. 다만 중요한 원칙은 물리적인데이터베이스 모델링에 맞추는 것이 아니라
  • 155. 논리적인 데이터베이스 모델링 에 맞춰 나누는 것입니다
  • 156. 이러한 점은 VO 설계에도 마찬 가지입니다
  • 157. VO의 필드를 물리적인 데이터베이스 필드와 동일하게 맞추 지 마세요
  • 158. 컴퓨터는 기계지만 여러분은 사람입니다
  • 159. 컴퓨터가 융통성이 없다면 여러분이 융통성 있게 코드를 작 성하면 됩니다
  • 160. 물론 반드시 다르게 만들라는 말은 아닙니다
  • 161. 어째튼 데이터베이스의 필드명 과 VO의 필드명이 다르므로
  • 162. alias를 사용해서 매퍼에게 알 려줘야 합니다
  • 163. AS로 각각의 필드에 별칭을 만들어주세요
  • 164. alias로 만든 이름과 vo의 이름이 같으면 myBatis가 set 메서 드로 넣어서 리턴해줍니다
  • 165. 또한myBatis는 강력한 기능을 많이 가지고 있는데
  • 166. dynamic query를 작성하기에 도 매우 편리합니다
  • 167. 사실 대부분의 검색 조건은 파라 메터가 있냐없냐 이거죠
  • 168. myBatis는 data type을 반드시 알려줘야 하기 때문에
  • 169. 만약 처음 도입하게 된다면
  • 170. parameter type과 returntype 때문에 고생할 수도 있습 니다
  • 171. 매퍼와 관련해서 오류가 나는것은 data type이 달라서 그렇 습니다
  • 172. 정리
  • 173. 소스 코드를중복하여 작성하지 말라
  • 174. 위험요소는원천적으로 차단하라
  • 175. 로직은 반드시 존재해야 하는 곳에만 존재해야 한다
  • 176. 한 객체에 하나의 책임을 갖도 록 설계하라
  • 177. 특정 구현이 아닌 인터페이스 에 맞춰 프로그래밍하라
  • 178. 후라이드 반 양념 반
  • 179. 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
  • 180. 고맙습니다

×