DB SQL에서 사용하는 insert, update, delete 대신에 save, modify, remove 로 변경해서 사용하는 것에도 익숙해졌네요. ^^;

insert -> save update -> modify delete -> remove

DB 명령과의 연계성을 제거한다는 이유로 그렇게 사용한다고 하면서 사용하게 되었는데, 많이 익숙해졌습니다.

웹에서 put delete 이런 메소드 지원하나요? 저는 jsp쪽은 domainForm.jsp domainView.jsp 이렇게 합니다. 파일찾기가 편해서. . . 도메인이 많아지면 같은 파일이 많이 나와서 불편하더라구요.

@ezblog jsp 파일명이 중복되어 불편한 점은 맞다. 지난 번 프로젝트에서 파일명이 같아도 그리 큰 불편함은 느끼지 못해서 위와 같이 진행했다. put, delete는 당연히 지원하지 않는데 spring mvc에서 hidden 값을 통해 put, delete 메소드로도 개발할 수 있도록 지원하고 있다. 이 방식 활용해서 URL은 같아도 메소드를 달리해 개발할 수 있었다. spring mvc의 form 태그 확인해 보면 관련 내용 나온다.

@자바지기 스프링이 아니더라도 hidden으로 메소드지원하게 하는 경우도 있다고 어느책에서 봤었는데 지금까지 그렇게 써본적이 없었네요. 그런데 앞으론 클라이언트가 다양해지니 http 메소드를 정확히 쓰는것이 좋을것 같습니다.

@ezblog 어차피 http 인자로 전달하는 것이기 때문에 다양한 클라이언트를 지원하는데 이슈는 되지 않을 듯하다. spring mvc의 경우 _method라는 이름으로 put을 전달하면 PUT 메소드로 인식하기 때문에 이슈가 되지는 않을 듯하다. 그 보다는 가능하면 restful 방식처럼 깔끔한 url을 가져가는 것이 더 좋지 않을까 생각한다.

개인적으로는 controller 패키지 밑에 있으면 controller 이기 때문에 추가적인 suffix 는 활용하지 않습니다. 설명을 두번 하는 느낌이라서요.

REST 기반이라면, Controller 자체가 일종의 Repository로 동작하기 때문에, Controller 라는 naming이 맞는지도 좀 이슈가 있겠네요.

지금이야 Rails로 개발 중이니, 디렉토리 구조 같은건 잘 되어 있는 편이지만, 여전히 Controller + Controller 라는 괴상한 이름(ㅎㅎ 좀 괴상하더라고요. 난 Item Controller in Controller야!)은 맘에 안드는 편입니다.

이견이 좀 있겠지만, 사소한 Naming 이슈 제외하고는, REST 기반 Controller 쪽 네이밍은 Rails 나 Play 쪽이 잘 되어 있는거 같습니다. 정리도 좀 잘 되어 있는편이고.

PUT / DELETE의 경우, 대부분의 브라우저는 지원하지 않으나, API 형태로 제공할 부분을 생각해 보시면 맞춰서 개발하시는게 나아 보입니다. 특히 저 처럼 curl 로 API 테스트 하는 경우에는 정상적으로 PUT / DELETE 호출을 보내 볼 수 있기 때문에, 설정 한번만 맞추시는 편이 편할거에요.

Admin Controller의 경우, 저는 package 구분을 선호 합니다. Naming에 추가되기에는 좀 범위가 달라보여서요.

View의 경우에는, 주로 action name mapping을 사용하지만, 화면 단 개발자가 따로 있는 경우에는 이야기 해서 결정합니다. 서버 개발자가 건드리기 보다는 화면을 주로 다루는 분들이 확실히 layout 나누는 거나, fragment 나누는거에 센스가 좋더라고요.

@Kenny Controller + Controller라는 것이 잘 이해가 안된다. 이 부분에 대해 좀 더 구체적으로 설명해 줄 수 있을까? Admin Controller의 경우 이전 회사에서는 아예 모듈이 분리되어 있었다. 예를 들어 다음과 같은 구조로..

archeage - aa-core - aa-web - aa-admin-web

하지만 위와 같이 구분을 둔 이유는 Ctrl + Shift + T로 클래스를 찾을 때 좀 찾기 쉽게 하려고 Adm을 추가해서 관리했다.

Rails와 Play쪽 함 보고 정리해 봐야겠다. 혹시 이와 관련해 정리한 있으면 공유 좀 해주라.

@자바지기

단순하게 예를 들자면, net.slipp.qna.controller.ReviewController 자체가, controller namespace 안에 있는 ReviewController 니까, Review Controller in Controller namespace 라는 의미에요. 어차피 namespace 가 controller면, model 이나 utility가 controller package 밑에 들어갈 리 없으니, 당연히 ReviewController는 Review 가 되어야 하지 않을까요?

admin 같은 경우에도, 저 같은 경우에는 net.slipp.qna.controller.admin.Review 혹은 net.slipp.qna.admin.controller.Review 쪽을 선호 합니다. (같은 의미에서요.)

Rails Directory Structure 는 다음과 같습니다.

http://www.rorexperts.com/rails-3-application-directory-structure-t2217.html

사실, rails new project_name 하면 기본으로 생성되는 README 파일에 아주 친절하게 내용 설명이 되어 있긴 한데... 대부분 안읽죠. :)

디렉토리 구조 보시면 아시겠지만, 생각보다 많이 직관적이에요. 일부 소소한 요구사항에 맞춰서 커스터마이징 하면 대부분의 프로젝트에 바로 적용 가능한 구조 입니다. (Rails 를 안써도, 디렉토리 구조 자체는 충분히 직관적입니다.)

Play Framework 같은 경우에도, Rails 영향을 많이 받아서, 비슷하게 가져갑니다.

http://www.playframework.org/documentation/2.0.4/Anatomy

큰 줄기에서 유사하죠?

여기서, 저 같은 경우에는 한발 더 나아가서, 어차피 Model Namespace 밑에 있을꺼면 model 이라는 suffix 는 의미가 없고, controller namespace 밑에 있을꺼면 controller 라는 suffix 도 사족에 불과하다는 쪽 입니다.

말씀하신 구조로, 프로젝트를 나누더라도 어차피 namespace 랑은 상관 없는 이야기이기 때문에, 저라면 aa-web 에는 com.xlgames.archeage.controller 라는 namespace 가 있을꺼고, aa-admin-web 쪽에는 com.xlgames.archeage.admin.controller (혹은 com.xlgames.archeage.controller.admin) 이라는 namespace가 있을거니, Controller의 suffix 인 Controller는 별 의미가 없어 보이네요. ^^;;;

사족으로...

net.slipp.qna.controller.ReviewController 를 허용하니까, net.slipp.qna.controller.ReviewUtils가 허용되는 느낌입니다. 사실 controller namespace에는 controller 가 들어가야 하는데, 그 안에 있는 클래스들이 한결같이 Controller라는 suffix 를 달고 있다면... suffix 만 달리해서 다른 일을 하는 class가 들어가면 안되는 이유가 없어 보여요. (이게 필요한 경우도 있겠지만, 대부분의 경우에는 큰 의미 없죠...) 또 하나, 저렇게 구분 할 수록, Review Model에 Review Controller + Review View가 생기는 경우를 많이 봤습니다. (이건 다른 스타일로 가도 마찬가지겠지만요.) 어차피 다 Review면 Domain 구분이 큰 의미가 없어 보입니다. 좀 더 용도에 맞는 이름을 찾아서 구분해 주는 쪽이 좋다고 봅니다.