크하하핫;; 테러가 응징을 당했군요;;ㅋ
1. 닥치고 쓰라는 말에 대해선요... 말자체에 대한 어감은 뭐 나쁘진 않게 들리는데(비슷하게 즐겨 쓰는 말이있기 때문에욥;;ㅋ- 걍 닥치고 찌그러져 있어;; 뭐 이런말들..? ) 일을 하는데 있어서 들으면 기분좋은 이야기는 아니더라구요.. 들어보니;; 전 그랬습니다.. 더욱더 분발하게 되더라구요... ;;
2. 독학하려고 여기저기 기웃거리다... - 여기에 대해선요.. 물론 자~ 스프링 교육합니다.. 모이세요~ 이러면 정말 좋은 기회죠;; 하지만 ... 저도 독학으로 많이 기웃거렸습니다.. 끝도 안보이는 인터넷 바다에서 어려운 글들을 보면서 이건 도대체 정체가 머야;;ㅡㅡ;; 이랬죠;; 물론 지금도 그렇치만요... ;; 스프링이 좋다 스트럿츠가 좋다.. 이런 말에 하던 독학을 접고 새로운걸 한다는건... ;; 저같은 우유부단한 성격의 소유자 들이군요.. 그건 스프링이 좋타 스트럿츠가 좋타를 떠나서 C가 좋니 JAVA가 좋니;; 뭐 이런거랑 비슷하다고 봅니다~;; 하고 싶은거 해야죠;; 아니 하려고 노력해야죠;;
3. 프레임워크 몇개 GG .. - GG 쳤다고 오도가도 못하는 상황........ 글쎄요.. 제가 경험은 짧지만... 정말 아무것도 몰라도 돈 벌기 위해서 그냥 남들한거 대충 짜집기 하다고 하다가 정모르면 주위에 만만한 사람잡고서 떠 넘기더라구요.. 1년여 가까이 스프링 프레임웍을 사용하여 개발하는데도.. 많은사람들이 인지를 잘 안하더라구요... 걍 이렇게 쓰면되.. 뭐 이런 패턴만 찾아서 일하는 경우가 대다수를 차지 하더구요..
4. 개발자 이야기인데요.. 전 그냥 제목을 보고 "자바와 스프링프레임워크 사이" 이것만 봤을때 첨에 딱 들은 생각이 개발자가 사이에 있는거 아닌가? 싶었거든요.. 그렇치 않나요 ? 개발자가 자바언어로 스프링프레임웍을 활용해서 개발한다.. 이런 의미였었죠;; 개발자가 어떻게 하느냐가 중요할 것 같았습니다..프레임웍을 쓰는것도 제대로된 OOP를 보다 좀 쉽게 구현해보자고 사용하는 JAVA라는 도구의 도움의 도구가 아닌가요? 주어진 JAVA와 그 JAVA를 이용해서 좀더 편리하고 쉽게 완성할수 있도록 도와주는 프레임웍 도구.. 그리고 그걸 사용하는건 개발자.. ;; 뭐 이런취지라고 할 수 있겠네욥;; 제가 머 잘났다고 개발자를 비하하겠습니까;;ㅋ 제 앞길 헤쳐나가기도 힘든 상황에;^^;;
5. 둘 사이에서 위험하게 툴타기 & 람보와 코만도. 참호속의 사람들.. - 이건.. 비유가... ;; 일단.. 자바와 스프링 둘 사이에서 줄타기 .. 무슨의미 일까요? 둘의 비교는 좀.. 전 잘 이해가 안가네요.. 왜 둘 사이에서 줄타기를 할까요...;; 그리고 람보와 코만도. 참호속의 사람들..;; 이것 또한 취향의 차이일듯합니다. 스프링을 다 좋아하라는 법없잖아요. EJB를 좋아하는 사람은 EJB좋아 할것이고.. 난 다 필요 없어.. 원빵JSP가 최고야 하는 사람은 그게 최고일것이고 .. 다만 프로젝트가 어떤거에 걸렸냐에 따라서 다르겠지만;; 스프링이 .. 프레임웍들이 싫다고 개발자 그만둬 ~ 이러는건.. 좀 아니라고 봅니다.. ;; 프레임워크 없이도 잘 돌아가니.. 왜 쓰냐는 사람도 당연히 있겠죠;; 프레임웍을 놓고 개발자를 그만두니.. 이러는건.. 할리웃 액션인듯 합니다.
흠냥;; 답글을 달다 중간에 날러가서 다시 적다 보니.. 꾀 많은 시간이 흘렀네요;; 좀더 적으면 한시간을 찍겟는데요.. 신중하게 생각을 하지 못하고 얼렁뚱당 답글 하나 적은 하수의 실수 입니다.ㅋ
진지한 글에는 정확한 표현으로 응답 하겠습니다..;; 오랜만에 올라온 글인지라.. 답글을 달고 싶은 충동이 생겨서 그만.. 질러버렸습니다.^^;;
마지막으로 ~ 스프링을 쓰는 합리적인 근거 .. 이건.. 다음 모임이 스프링기초부터 활용까지 총 2번의 스터디의 마지막이니까.. 다같이 한번... 토론의 장에서 이야기를 해보는게 어떨까요? 일단 시작은 극찬들을 하길래 뭔가;; 해서 시작은 했죠;;ㅋ 나머지는.. ;; 스터디 떄??? ^^
1. 닥치고 쓰라는 말에 대해선요... 말자체에 대한 어감은 뭐 나쁘진 않게 들리는데(비슷하게 즐겨 쓰는 말이있기 때문에욥;;ㅋ- 걍 닥치고 찌그러져 있어;; 뭐 이런말들..? ) 일을 하는데 있어서 들으면 기분좋은 이야기는 아니더라구요.. 들어보니;; 전 그랬습니다.. 더욱더 분발하게 되더라구요... ;;
2. 독학하려고 여기저기 기웃거리다... - 여기에 대해선요.. 물론 자~ 스프링 교육합니다.. 모이세요~ 이러면 정말 좋은 기회죠;; 하지만 ... 저도 독학으로 많이 기웃거렸습니다.. 끝도 안보이는 인터넷 바다에서 어려운 글들을 보면서 이건 도대체 정체가 머야;;ㅡㅡ;; 이랬죠;; 물론 지금도 그렇치만요... ;; 스프링이 좋다 스트럿츠가 좋다.. 이런 말에 하던 독학을 접고 새로운걸 한다는건... ;; 저같은 우유부단한 성격의 소유자 들이군요.. 그건 스프링이 좋타 스트럿츠가 좋타를 떠나서 C가 좋니 JAVA가 좋니;; 뭐 이런거랑 비슷하다고 봅니다~;; 하고 싶은거 해야죠;; 아니 하려고 노력해야죠;;
3. 프레임워크 몇개 GG .. - GG 쳤다고 오도가도 못하는 상황........ 글쎄요.. 제가 경험은 짧지만... 정말 아무것도 몰라도 돈 벌기 위해서 그냥 남들한거 대충 짜집기 하다고 하다가 정모르면 주위에 만만한 사람잡고서 떠 넘기더라구요.. 1년여 가까이 스프링 프레임웍을 사용하여 개발하는데도.. 많은사람들이 인지를 잘 안하더라구요... 걍 이렇게 쓰면되.. 뭐 이런 패턴만 찾아서 일하는 경우가 대다수를 차지 하더구요..
4. 개발자 이야기인데요.. 전 그냥 제목을 보고 "자바와 스프링프레임워크 사이" 이것만 봤을때 첨에 딱 들은 생각이 개발자가 사이에 있는거 아닌가? 싶었거든요.. 그렇치 않나요 ? 개발자가 자바언어로 스프링프레임웍을 활용해서 개발한다.. 이런 의미였었죠;; 개발자가 어떻게 하느냐가 중요할 것 같았습니다..프레임웍을 쓰는것도 제대로된 OOP를 보다 좀 쉽게 구현해보자고 사용하는 JAVA라는 도구의 도움의 도구가 아닌가요? 주어진 JAVA와 그 JAVA를 이용해서 좀더 편리하고 쉽게 완성할수 있도록 도와주는 프레임웍 도구.. 그리고 그걸 사용하는건 개발자.. ;; 뭐 이런취지라고 할 수 있겠네욥;; 제가 머 잘났다고 개발자를 비하하겠습니까;;ㅋ 제 앞길 헤쳐나가기도 힘든 상황에;^^;;
5. 둘 사이에서 위험하게 툴타기 & 람보와 코만도. 참호속의 사람들.. - 이건.. 비유가... ;; 일단.. 자바와 스프링 둘 사이에서 줄타기 .. 무슨의미 일까요? 둘의 비교는 좀.. 전 잘 이해가 안가네요.. 왜 둘 사이에서 줄타기를 할까요...;; 그리고 람보와 코만도. 참호속의 사람들..;; 이것 또한 취향의 차이일듯합니다. 스프링을 다 좋아하라는 법없잖아요. EJB를 좋아하는 사람은 EJB좋아 할것이고.. 난 다 필요 없어.. 원빵JSP가 최고야 하는 사람은 그게 최고일것이고 .. 다만 프로젝트가 어떤거에 걸렸냐에 따라서 다르겠지만;; 스프링이 .. 프레임웍들이 싫다고 개발자 그만둬 ~ 이러는건.. 좀 아니라고 봅니다.. ;; 프레임워크 없이도 잘 돌아가니.. 왜 쓰냐는 사람도 당연히 있겠죠;; 프레임웍을 놓고 개발자를 그만두니.. 이러는건.. 할리웃 액션인듯 합니다.
흠냥;; 답글을 달다 중간에 날러가서 다시 적다 보니.. 꾀 많은 시간이 흘렀네요;; 좀더 적으면 한시간을 찍겟는데요.. 신중하게 생각을 하지 못하고 얼렁뚱당 답글 하나 적은 하수의 실수 입니다.ㅋ
진지한 글에는 정확한 표현으로 응답 하겠습니다..;; 오랜만에 올라온 글인지라.. 답글을 달고 싶은 충동이 생겨서 그만.. 질러버렸습니다.^^;;
마지막으로 ~ 스프링을 쓰는 합리적인 근거 .. 이건.. 다음 모임이 스프링기초부터 활용까지 총 2번의 스터디의 마지막이니까.. 다같이 한번... 토론의 장에서 이야기를 해보는게 어떨까요? 일단 시작은 극찬들을 하길래 뭔가;; 해서 시작은 했죠;;ㅋ 나머지는.. ;; 스터디 떄??? ^^
토비님 글을 읽고, 메신저로 잠시 대화를 나누다가 문득 제목과 같은 생각을 해봤습니다.
자바와 스프링 사이에는 무엇이 있을까요?
대한민국 1%의 개발자가 모르는 게 아니라, 99%의 개발자가 모르는 게 스프링 프레임워크라고 생각합니다.
모르는 사람 중에 저도 포함해서 말이죠. 아직은 수박의 껍질만 우적우적 찝어 보았을 뿐이니까요.
아는 척 안하겠습니다. 요즘 물어뜯기 좋아하는 사람들이 많아서~ ^^;
잘 아시는 분도 계시겠지만, 프로 스포츠 선수라고 해도 늘 기초 체력 단련은 하는 거니까,
그런 측면에서 생각해 보자, 함께 얘기해 보자는 것이죠.
소프트웨어 개발자가 되기 위해서 가장 먼저 배우는 것이 프로그래밍 언어이고,
요즘 가장 많은 개발자가 학습하는 언어 중에 자바가 빠지지 않을 겁니다.
프로그래밍 언어 자체를 배우는 건 그리 어려운 일이 아닐겁니다. 그러나, 응용하기는 쉽지 않죠.
자신만의 성과라고 할까요? 작품이라고 할까요. 언어를 배우는 데 걸리는 시간도 꽤 드는데,
언어를 학습하고 나서도 자신만의 작품을 만드는 건 쉽지 않죠.
왜 그럴까 늘 생각해 봅니다. 자바가 아닌 다른 언어로 개발할 때는 그나마 쉽죠.
PHP를 배우고 아파치 웹 서버만 설치하면 웹 사이트 뚝딱 만들고,
Action Script를 공부하면 간단하나마 Flash 어플리케이션을 만들 수 있고,
Visual C++이나 Visual Basic을 학습하면 초기부터 어플리케이션 제작이 가능하죠.
그런데 자바는 그렇지 못하잖아요? 물론 ansi C 언어를 가지고 무언가를 만드는 것보다는 쉽지만 말입니다.
어찌 보면 참 까탈스러운 언어가 아닌가 라는 생각도 들고...
게다가, 프레임워크까지 이해하려면 더욱 험난한 길입니다.
그래서, 자바 개발을 하는 사람을 위해서 로드맵(loadmap)이 제시되어야 할 필요가 있지 않을까 하는
생각을 해봤습니다. 자바에서는 참 배울게 많거든요. 그런데 무엇부터 배워야 할지 나름 오래 공부한
저도 섣불리 얘기하기가 어렵습니다. 여전히 모르는게 더 많으니까요...
하여간, 본론은 별거 없는데 주저리 주저리 늘어놓았네요.
다시 여쭤볼게요. 자바와 스프링 사이에는 무엇이 있을까요?
스프링 프레임워크는 그냥 닥치고 써야 하는 건가요?
[덧]
질문만 냅다 던져놓으니 좀 무책임한 것 같고, 영회님 덧글을 주셔서 제 의견을 하나 추가해 봅니다.
자바 혹은 JDK(Java Development Kit)는 훌륭한 플랫폼(platform)이지만
그 자체로서는 비지니스 시스템을 구축할 수 없습니다.
만들다 만 것이 아니라, 기반 환경(infra system)이라는 개념 자체에 충실한 것이라고 봐야겠죠.
어떤 구체적인 목적을 잘 수행할 수 있는 시스템은 다른 목표 혹은 대상에 적용하기가 어렵기 때문입니다.
예를 들자면 자동차 엔진을 가져다 비행기에 쓸 수 없고, 선박용 엔진을 트럭에 탑재하기 어려운 것처럼 말입니다.
못한다고 선을 긋기는 어렵지만 또 그렇게 쉬운 일도 아닌 것이죠.
글을 쓴 본래의 취지는 이렇듯 자바 혹은 개발 언어를 바라보는 시선을 넓혀보자는 것입니다.
언아가 모든 것을 채워주지 않는 것 같습니다. 프로그래밍 언어는 가장 기본적인 요소만을 제공할 뿐이죠.
스프링 스터디 클럽을 오시는 분들에게는 어쩌면 상식적인 얘기일지도 모르지만,
그런데 현장 그리고 개발자 지망생들은 어떻게 생각하고 있을까요?
자바를 공부한다는 것, 그중에서 자바 언어를 조금 안다는 것은 거의 자바라는 세상을 모르는 것과 같다는 시각.
이런 의견이 상식이 되었으면 좋겠습니다. 그게 가능할지 모르지만 말입니다.
왜 스프링 프레임워크를 사용해야 하는가 하는 질문에 대한 질문자 자신의 생각이었습니다.
제가 스터디 초반에 다른 사람들의 코드를 보고 리뷰를 하자고 했는데 사실상 스터디 시간에 리뷰를 하기란 참으로 빠듯하더군요. 그렇쵸? 그래서 지금 소스 관리 저장소에 올라온 성윤님 코드를 받아서 잠깐 들여다 봤습니다.(다른 분들 코드도 올려주시면 좋겠네요. 아란님과 써니님 게시판 소스도 보고파요.)
이놈은 /*/category/* 이건 ... 화면에서 넘길때 .. /home/해당유저id/catagory/(카테고리 번호) 를 받는 놈이라서 * 로 했어요~ 그러니가;; 보통 catagoryID를 파리미터로 넘기지 않고 저런식으로 넘겨보려고요;;ㅋ
티스토리가 저런식이길래;; 흉내를 내보았네욥;ㅋ 그런데 저런 것 때문에 한동안 마니 삽질을 했다는..ㅋ
/*/category/여기 뒤에는 단순히 카테고리 번호만 옴!
카테로리 클래스에 private BbsDao bbsDao; 요넘의 접근제어자를 private 로 두고 test코드를 작성하다 보니.. 불가피 하게 set 메소드가 생겼네욥;; mock 객체를 대신 넣으려구요...ㅋ
이놈은 음.. 카테로리 네임 정보를 가져 오는 놈인데요;;ㅋㅋ
저기 맵에서 꺼내는건;; 마땅히 컨트럴러에서 받아온값을 서비스계층으로 넘기고 그값들을.. 서비스 계층에서 담으려다가 걍;; 도메인 계층에서 한번 담아 본거였어요;;ㅋㅋ 물론 어정정하게 DDD를 해보겠다고 해서 들여댔다가 나온 파생코드죠;;ㅋㅋ 쑤레기 코드..ㅋ
화면에서 널이 넘어 와서 널은 N으로 치환 해줘야 하는 걸 해주어야 하는데;; 쿼리에서 NVL로 할까;; 아님 다른데서 널치환을 할까 하다가 ;;; 여기에 자리 잡았네요;; ㅋ
음 이놈은... 해당 넘어온 카테고리 번호가 전체 카테고리 번호인지를 체크하는 놈인데요... 우선 맵을 던진이유는 해당 인자값에 해당하는 놈이 전체 카테고리에 해당하는 놈인지 쿼리를 한번 날리고 그 결과값이 맵으로 리턴되어서 그 맵안에 FULL_YN 값이 Y 이냐 N 이냐에 따라 달라지는 코드인데;;
public boolean checkFullCategory(Map<String, String> paramMap)
{
이렇게 되어 지네요;; 결과가 Map으로 리턴이 되어서 인자로 넘긴 맵의 값을 꺼내서 체크 하는것처럼 절못보였는건가;;; 음.. 일단 ;; 페스~ㅋㅋ
ㅋㅋ 영작하는데 소질이 없어서요;;ㅋ 어떤 이름을 지을까 이래 저래 하다가 ;;; 먼가 하나 남겨 볼까 해서;;ㅋ 넣어봤죠;;^^;;; 그 머냐 ... 낙서기질이라고 할까욥;;ㅋㅋ
이상.. 다소 까칠하게 쓰기도 했지만 좋게 봐주시리라 생각합니다. ^^
전체적으로 Map 사용과 3항 연산자 코드가 눈에 띄네요. 캬~ 역시 소스는 직접 다운받아서 봐야 잘 보이네요. 다른 분들도 받아서 함 봐 보시죠. 저장소가 저희 회사 서버에 있어서 굉장히 빠르답니다.ㅋㅋ
메이븐 프로젝트보다 일반 프로제긑가 좋은 점
- 대부분의 경우 JRE 설정만 잡아주면 프로젝트에 에러는 없다.
안 좋은 점
- SVN에서 lib 파일 받느라 체크 아웃이 조금 오래 걸린다.
- 대부분의 경우 JRE 설정만 잡아주면 프로젝트에 에러는 없다.
안 좋은 점
- SVN에서 lib 파일 받느라 체크 아웃이 조금 오래 걸린다.
아직 메이븐을...접해보지 못했어요;;ㅋㅋ
설정파일이 뭔가.. 이상함...
- applicaionContext.xml이라고 되어 있어야 할 것들이 모듈별로 여러 개의 xxx-servlet 으로 쪼개져 있고 xxx-servlet 에 들어가있어야 할 것이 applicationCotnext.xml 이라는 이름의 설정 파일에 들어가 있음. @_@
- 성윤님께서 스프링 MVC에서 applicatonContext와 dispatcherServlet이 사용하는 webapplicationContext 계층 구조를 햇갈리신 걸까? 아니면 어떤 의도로 저렇게 나눠두신 걸까??
- 설정 파일의 위치도 이상함. applicationContext.xml은 보통 src 폴더에 두어야될 것 같고(설정 파일은 관련된 코드 근처에 두는게 좋겠다는 취지에서..) xxx-servlet은 WEB-INF 밑에 두면 될 것 같은데.. applicationContext가 WEB-INF 밑에 있네요. test 폴더 밑에는 테스트용 applicationContext가 있어야 하는데 그 이름이 역시 test-servlet이라고 되어 있어서.. 뭔가 좀.. 이름이 별로네요.
- applicaionContext.xml이라고 되어 있어야 할 것들이 모듈별로 여러 개의 xxx-servlet 으로 쪼개져 있고 xxx-servlet 에 들어가있어야 할 것이 applicationCotnext.xml 이라는 이름의 설정 파일에 들어가 있음. @_@
- 성윤님께서 스프링 MVC에서 applicatonContext와 dispatcherServlet이 사용하는 webapplicationContext 계층 구조를 햇갈리신 걸까? 아니면 어떤 의도로 저렇게 나눠두신 걸까??
- 설정 파일의 위치도 이상함. applicationContext.xml은 보통 src 폴더에 두어야될 것 같고(설정 파일은 관련된 코드 근처에 두는게 좋겠다는 취지에서..) xxx-servlet은 WEB-INF 밑에 두면 될 것 같은데.. applicationContext가 WEB-INF 밑에 있네요. test 폴더 밑에는 테스트용 applicationContext가 있어야 하는데 그 이름이 역시 test-servlet이라고 되어 있어서.. 뭔가 좀.. 이름이 별로네요.
푸핫;; 어떻게 하다보니.. ㅋ 우선.. 머라고 할까;; xxx-servlet.xml 파일들이 WEB-INF밑에 바로가 있는 모습이 맘에 들지 않아서 폴더를 하나 만들어서 그곳에서 또 모듈 별로 설정 파일을 나누려는 목적이었으나..
게시판에는 몇개의 설정파일들이 존재 하지 않게 되어서..ㅋ 구지 따로 옮길 필요 까지는 없었는데;;(따로 옮기면서 web.xml에도 구지 해당 xml위치를 적어주어야 했음.) ;; 전에 프로젝트 할때 .. 너무 많은 설정 파일들이 산재하게 되어;; 어떻게 정리가 되지 않을까 싶어서 시도해보았고..xxx-servlet.xml 파일내용과 applicationContext.xml 파일 설정내용이 좀 이상 애매모호 하게 된건.. xxx-servlet.xml 설정파일을 나누다 보니 공통적으로 적용될건 applicationContext.xml로 빼버리게 되엇는데;; 나중에는 init-servlet.xml 파일이 하나 생기고 ㅡㅡ;; 뭐 이래저래 막무가내로 코딩하게 되었네요;;ㅋ test관련해선.. 걍 즉흥적으로;;ㅋㅋ
게시판에는 몇개의 설정파일들이 존재 하지 않게 되어서..ㅋ 구지 따로 옮길 필요 까지는 없었는데;;(따로 옮기면서 web.xml에도 구지 해당 xml위치를 적어주어야 했음.) ;; 전에 프로젝트 할때 .. 너무 많은 설정 파일들이 산재하게 되어;; 어떻게 정리가 되지 않을까 싶어서 시도해보았고..xxx-servlet.xml 파일내용과 applicationContext.xml 파일 설정내용이 좀 이상 애매모호 하게 된건.. xxx-servlet.xml 설정파일을 나누다 보니 공통적으로 적용될건 applicationContext.xml로 빼버리게 되엇는데;; 나중에는 init-servlet.xml 파일이 하나 생기고 ㅡㅡ;; 뭐 이래저래 막무가내로 코딩하게 되었네요;;ㅋ test관련해선.. 걍 즉흥적으로;;ㅋㅋ
인터페이스 사용 일관성 문제
- DAO는 인터페이스를 사용했으나 서비스에는 사용하지 않았네요. 사용하려면 다 쓰고 안 쓰려면 다 안 쓰지. 왜 그렇게 하셨을까요?(참고로 전 다 안 썼답니다.ㅋㅋㅋㅋ)
- DAO는 인터페이스를 사용했으나 서비스에는 사용하지 않았네요. 사용하려면 다 쓰고 안 쓰려면 다 안 쓰지. 왜 그렇게 하셨을까요?(참고로 전 다 안 썼답니다.ㅋㅋㅋㅋ)
ㅋㅋ 원래 기존에는 서비스와 DAO에 전부 인터페이스가 자리 하고 있었으나... 문득 드는 생각이 이놈이 여기 왜 있을까;;; 해서 없애 버렸음..ㅋ 그나마 DAO는 기존 JDBC로 구현한놈과 아이베티스를 적용해서 구현한놈을 둘다 가져가볼까 해서;;ㅋㅋ 두었는데;; 뭐 아직 미완성이라;;ㅋ
컨트롤러에서 유일한 Servlet API = HttpSession.
- 2.X 대에서는 불가피하지만, 3.0부터는 @Session인가 하는 애노테이션을 사용해서 세션에 있는 attibute를 자동으로 메서드 매개변수로 바인딩해서 사용할 수 있다고 하네요.
- 2.X 대에서는 불가피하지만, 3.0부터는 @Session인가 하는 애노테이션을 사용해서 세션에 있는 attibute를 자동으로 메서드 매개변수로 바인딩해서 사용할 수 있다고 하네요.
굳 인데요;;ㅋ
request mapping 범위가 너무 넓은거 아닐까요?
- @RequestMapping("/*/category/*")
public String getCategoryInPostSch(HttpServletRequest req,HttpSession session, ModelMap map)
{ ...
이런 코드가 있던데 저 메소드가 실제로는 요청 하나만 처리할 텐데 범위가 *로 너무 넓게 되어 있는 듯 합니다.
- @RequestMapping("/*/category/*")
public String getCategoryInPostSch(HttpServletRequest req,HttpSession session, ModelMap map)
{ ...
이런 코드가 있던데 저 메소드가 실제로는 요청 하나만 처리할 텐데 범위가 *로 너무 넓게 되어 있는 듯 합니다.
이놈은 /*/category/* 이건 ... 화면에서 넘길때 .. /home/해당유저id/catagory/(카테고리 번호) 를 받는 놈이라서 * 로 했어요~ 그러니가;; 보통 catagoryID를 파리미터로 넘기지 않고 저런식으로 넘겨보려고요;;ㅋ
티스토리가 저런식이길래;; 흉내를 내보았네욥;ㅋ 그런데 저런 것 때문에 한동안 마니 삽질을 했다는..ㅋ
/*/category/여기 뒤에는 단순히 카테고리 번호만 옴!
굳이 세터는 만든 이유는?
- @Autowired
public void setBbsDao(BbsDao bbsDao)
{
this.bbsDao = bbsDao;
}...
Category 클래스에 이런 코드가 있었습니다. 세터 없이 그냥 @Autowired를 필드에 붙여주면 되는데 왜 세터를 만들고 메소드 위에 붙여두셨죠? 세터가 필요한 이유라도 있는건가요?
- @Autowired
public void setBbsDao(BbsDao bbsDao)
{
this.bbsDao = bbsDao;
}...
Category 클래스에 이런 코드가 있었습니다. 세터 없이 그냥 @Autowired를 필드에 붙여주면 되는데 왜 세터를 만들고 메소드 위에 붙여두셨죠? 세터가 필요한 이유라도 있는건가요?
카테로리 클래스에 private BbsDao bbsDao; 요넘의 접근제어자를 private 로 두고 test코드를 작성하다 보니.. 불가피 하게 set 메소드가 생겼네욥;; mock 객체를 대신 넣으려구요...ㅋ
잘 이해가 안 되는 코드
- public Category getCategoryName(Map<String, String> paramMap)
{
bbsId = paramMap.get("bbsId");
cKey = paramMap.get("cKey");
fullYn = paramMap.get("fullYn");
bbsDao.getCategoryName(this);
return this;
}
이 코드는 무슨 일을 하는거죠? 보통 get으로 시작하는 메소드는 뭔가 리턴하고 그 리턴한 걸 받아서 쓰는 코드를 예상하기 쉬운데 위에 있는 getCate.. 를 따라가 봤더니 주석에 // 쓰레기 코드라고 되어 있네요. 크헉...ㅋㅋ
- public Category getCategoryName(Map<String, String> paramMap)
{
bbsId = paramMap.get("bbsId");
cKey = paramMap.get("cKey");
fullYn = paramMap.get("fullYn");
bbsDao.getCategoryName(this);
return this;
}
이 코드는 무슨 일을 하는거죠? 보통 get으로 시작하는 메소드는 뭔가 리턴하고 그 리턴한 걸 받아서 쓰는 코드를 예상하기 쉬운데 위에 있는 getCate.. 를 따라가 봤더니 주석에 // 쓰레기 코드라고 되어 있네요. 크헉...ㅋㅋ
이놈은 음.. 카테로리 네임 정보를 가져 오는 놈인데요;;ㅋㅋ
저기 맵에서 꺼내는건;; 마땅히 컨트럴러에서 받아온값을 서비스계층으로 넘기고 그값들을.. 서비스 계층에서 담으려다가 걍;; 도메인 계층에서 한번 담아 본거였어요;;ㅋㅋ 물론 어정정하게 DDD를 해보겠다고 해서 들여댔다가 나온 파생코드죠;;ㅋㅋ 쑤레기 코드..ㅋ
코드 스타일
- 저는 보통
public void do() {
/// 요렇게 이클립스 기본 스타일로 쓰는데..
}
성윤님은
public void do()
{
// 요렇게 비주얼베이직 기본 스타일처럼 쓰시네요.
}
- 저는 보통
public void do() {
/// 요렇게 이클립스 기본 스타일로 쓰는데..
}
성윤님은
public void do()
{
// 요렇게 비주얼베이직 기본 스타일처럼 쓰시네요.
}
ㅋㅋ 어떻게 하다보니... 습관이 저렇게 들어버렸네요;; if else if esle 뭐 이런것들 적을때;;
명확히 구분하기가 힘들어 보여서... 시작했던 코딩스타일인데요;; 시작하다보니.. 저렇게 굳어버렷네요;;
가끔은 헛 공간을 잡아먹어서;;ㅡㅡ;
명확히 구분하기가 힘들어 보여서... 시작했던 코딩스타일인데요;; 시작하다보니.. 저렇게 굳어버렷네요;;
가끔은 헛 공간을 잡아먹어서;;ㅡㅡ;
세터에 null 방지 코드
- public void setPostReplyYn(String postReplyYn)
{
this.postReplyYn =postReplyYn == null ? "N":postReplyYn;
}
이런 코드가 있던데.. 아무래도 null 방지 용으로 세터에 손을 쓴 것 같습니다. 음~ null 방지 코드라.. validation인지.. 기본값 세팅인지..흠.. 뭔가 좀 생각을 해봐야겠네요. 일반적인 기본 세터랑 차이가 있어서 당연히 기본 세터 겠거니하고 코딩을 하다가는 예상치 못한 결과를 볼 수 도 있겠군요.
- public void setPostReplyYn(String postReplyYn)
{
this.postReplyYn =postReplyYn == null ? "N":postReplyYn;
}
이런 코드가 있던데.. 아무래도 null 방지 용으로 세터에 손을 쓴 것 같습니다. 음~ null 방지 코드라.. validation인지.. 기본값 세팅인지..흠.. 뭔가 좀 생각을 해봐야겠네요. 일반적인 기본 세터랑 차이가 있어서 당연히 기본 세터 겠거니하고 코딩을 하다가는 예상치 못한 결과를 볼 수 도 있겠군요.
화면에서 널이 넘어 와서 널은 N으로 치환 해줘야 하는 걸 해주어야 하는데;; 쿼리에서 NVL로 할까;; 아님 다른데서 널치환을 할까 하다가 ;;; 여기에 자리 잡았네요;; ㅋ
왜 맵을 통쨰로 던졌을까?
- public boolean checkFullCategory(Map<String, String> paramMap)
{
return bbsDao.checkFullCategory(paramMap).get("FULLYN").equals("Y")?true:false;
}
이 코드를 보면 필요한 값만 넘기지 않고 맵을 통째로 던져서 코드가 길어진 걸 볼 수 있습니다. 물론 3항 연산자로 한 줄로 끝내긴 했지만. 그래도..왜 그런 원칙이 있자나요. 드리트리 원칙이던가.. 친한 친구랑만 얘기하라던.. 그걸 지킬 수도 있는데 위반한 대표적인 코드가 되겠네요.
- public boolean checkFullCategory(Map<String, String> paramMap)
{
return bbsDao.checkFullCategory(paramMap).get("FULLYN").equals("Y")?true:false;
}
이 코드를 보면 필요한 값만 넘기지 않고 맵을 통째로 던져서 코드가 길어진 걸 볼 수 있습니다. 물론 3항 연산자로 한 줄로 끝내긴 했지만. 그래도..왜 그런 원칙이 있자나요. 드리트리 원칙이던가.. 친한 친구랑만 얘기하라던.. 그걸 지킬 수도 있는데 위반한 대표적인 코드가 되겠네요.
음 이놈은... 해당 넘어온 카테고리 번호가 전체 카테고리 번호인지를 체크하는 놈인데요... 우선 맵을 던진이유는 해당 인자값에 해당하는 놈이 전체 카테고리에 해당하는 놈인지 쿼리를 한번 날리고 그 결과값이 맵으로 리턴되어서 그 맵안에 FULL_YN 값이 Y 이냐 N 이냐에 따라 달라지는 코드인데;;
public boolean checkFullCategory(Map<String, String> paramMap)
{
Map returnMap = bbsDao.checkFullCategory(paramMap);
if(returnMap.get("FULLYN").equals("Y")) return true;
return false;
if(returnMap.get("FULLYN").equals("Y")) return true;
return false;
}
이렇게 되어 지네요;; 결과가 Map으로 리턴이 되어서 인자로 넘긴 맵의 값을 꺼내서 체크 하는것처럼 절못보였는건가;;; 음.. 일단 ;; 페스~ㅋㅋ
트랜잭션 코드가 안보이네요.
- @Transactional 이라는게 안보이네요. transactionManager 빈이 등록된 건 확인을 했는데 말이죠. 흠. 트랜잭션 처리는 어떻게 하고 계신가요?
- @Transactional 이라는게 안보이네요. transactionManager 빈이 등록된 건 확인을 했는데 말이죠. 흠. 트랜잭션 처리는 어떻게 하고 계신가요?
일단 멍석만..ㅋㅋ 다음 코드 리뷰때 아마 등장할듯합니다..ㅋㅋ
HelolsResponse라는 클래스 이름이 맘에 안 듭니다.
- HeloIs 때문이 아니라 위에 서픽스가 영..;; 이 클래스가 AbstractView를 상속 받았다면 이 녀석도 View로 끝내는게 좋치 않을까요?
- HeloIs 때문이 아니라 위에 서픽스가 영..;; 이 클래스가 AbstractView를 상속 받았다면 이 녀석도 View로 끝내는게 좋치 않을까요?
ㅋㅋ 영작하는데 소질이 없어서요;;ㅋ 어떤 이름을 지을까 이래 저래 하다가 ;;; 먼가 하나 남겨 볼까 해서;;ㅋ 넣어봤죠;;^^;;; 그 머냐 ... 낙서기질이라고 할까욥;;ㅋㅋ
이상.. 다소 까칠하게 쓰기도 했지만 좋게 봐주시리라 생각합니다. ^^
전체적으로 Map 사용과 3항 연산자 코드가 눈에 띄네요. 캬~ 역시 소스는 직접 다운받아서 봐야 잘 보이네요. 다른 분들도 받아서 함 봐 보시죠. 저장소가 저희 회사 서버에 있어서 굉장히 빠르답니다.ㅋㅋ
일자 : 2008년 12월 28일(일요일)
시간 : 15:00 ~ 18:00
장소 : 종로토즈
참석자 : 기선, HeloIs, 써니, Hoyeol
코드리뷰 (토론)시간 :
시간 : 15:00 ~ 18:00
장소 : 종로토즈
참석자 : 기선, HeloIs, 써니, Hoyeol
코드리뷰 (토론)시간 :
금주 토요일 22:00까지 댓글 기준으로 스터디 룸 예약하겠습니다.
일이 바쁘단 핑계로 참석을 못하니 점점 방관자가 되가는거 같아 가슴이 아프네요 ㅠ ㅠ;
오픈 이후 2차 개발이 있지만 그래도 여유있어 지길 기대합니다 ㅠ ㅠ;
12월 28일 15:00 3시간 4-6인실 예약 완료 했습니다. 오늘 시스템 오픈입니다. 잘되서 일요일날 뵐 수 있기를 바랍니다^^
스프링을 이용한 게시판 개발 스터디가 끝나갑니다. 다음은 최종편으로 원래 목표로 했던 페이징 기능 구현을 선보일 예정입니다. 현재 주요 프로젝트는 두 개(HeloIS 성윤님의 게시판과 기선의 Whiteboard)입니다. 시작할 땐 써니님의 스트럿츠를 이용한 게시판과 아란님의 아라보드등을 비롯하여 여러 게시판들이 있었는데 현재 써니님의 게시판은 완료 상태를 확인했고 아란님은 회사일이 바빠지셔서 gg 비스무리하게 됐습니다.(혹시 모르죠. 2주 사이에 갑자기 구현해 오실지도ㅋㅋ)
현재 진행 중인 두 개 프로젝트 특징을 나열하면 다음과 같습니다.
성윤님 게시판
- DDD 시도
- @Configurable 사용.
- 로드 타임 위빙 사용.
- Mock 객체를 사용한 단위 테스트.
- 스프링 2.5.
- UI가 T모 블로그와 거의 흡사.
- 일반 자바 웹 프로젝트
- 프레임 나누지 않았음.
- 톰캣 server, external module 사용.
Whiteboard
- 일반적인 계층 구조.
- DBUnit을 사용한 DAO 테스트.
- 스프링 2.5.
- 스프링 시큐리티 2.0.
- 외관 허접.
- Maven 프로젝트
- 현재 프레임 나눠져 있는 상태(프레임셋 사용하지 않는 걸로 변경해야 함)
- 톰캣 server, external module 사용.
현재 진행 중인 두 개 프로젝트 특징을 나열하면 다음과 같습니다.
성윤님 게시판
- DDD 시도
- @Configurable 사용.
- 로드 타임 위빙 사용.
- Mock 객체를 사용한 단위 테스트.
- 스프링 2.5.
- UI가 T모 블로그와 거의 흡사.
- 일반 자바 웹 프로젝트
- 프레임 나누지 않았음.
- 톰캣 server, external module 사용.
Whiteboard
- 일반적인 계층 구조.
- DBUnit을 사용한 DAO 테스트.
- 스프링 2.5.
- 스프링 시큐리티 2.0.
- 외관 허접.
- Maven 프로젝트
- 현재 프레임 나눠져 있는 상태(프레임셋 사용하지 않는 걸로 변경해야 함)
- 톰캣 server, external module 사용.
Prev
Rss Feed