경험상 성능 차이 보다는 유지보수 시 에 복잡함에 헤매이며 치를 떠는 경험은 많이 해 봤네요...^^;

다른 분들도 어느정도 본인의 경험(?)에 따라서 분류를 해서 사용을 하는거 같은데...

너무 분리를 많이 해도 이래저래 좀 복잡하더라구여...

정답은 없는거 같습니다.
 

바보돌쇠 // 답변 감사합니다. 성능상 심하게 차이가 없다면 저는 모델을 합쳐놓으려고 생각중입니다.... 코드찾는데 시간이 다가는것 같아서... 수고하세요~

기능상으로 분리될 정도면 기획단에서 서비스가 분리될아야 합니다. 공통 모델을 사용하기도 하나 가급적이면 하나의 모델을 쓰는게 좋습니다. 유지보수면이나 기능구분상..

변종원(웅파) // 예를들면 회원이라는 모델을 만들어 놓고 회원가입 회원탈퇴 정보수정 등의 처리들을 한번에 하려고 하는데 현재는 각각의 모델들이 따로만들어져있어서 통합하려고 합니다. 이 경우에는 하나의 회원모델로 통합을 해야할지 그대로 분할해 놓아야 할지..

회원가입, 회원탈퇴 컨트롤러가 분리되어 있나요? ^^

변종원(웅파) // 음 아직 회원탈퇴에 대한 컨트롤러는 생성되어있지 않은데 따로 분리해야하는게 아닌지요?

반문하는 겁니다. 왜 작은 기능마다 컨트롤러를 만드는건가요?
클래스개념과 비슷하다고 생각하시면 됩니다.
회원 컨트롤러에 관련 메소드인 가입, 수정, 탈퇴, 로그인, 로그아웃이 들있고 모델 하나 연결하여 관리하면 됩니다.

변종원(웅파) // 아 네 답변 감사합니다~ 변명하자면 이게 제가 처음부터 개발하는게 아니라 틀정도만 잡혀있는 프로젝트를 제가 이해하면서 수정하는 중이라... 각각의 컨트롤러들로 분할되어있더라구요. 그래서 지금 확실하게 이해하고 필요없는부분들은 버려나가면서 리팩토링 하는 중입니다.. 답변 도움 되었습니다~

회원관리에서 컨트롤러가 분리될 정도라면 뭔가 특화된 기능이 있거나 특별히 많이 쓰는 기능이거나 등등
특정 이유가 있어야 한다라는거죠. 

하나의 프로젝트에서 필요에 의해 나눴다가 다시 합치기도 하고 그 기준은 사실 그때그때 달라요. ^^

변종원(웅파) // 네~ 많이 배워갑니다.