자유게시판

제목 어디까지가 컨트롤러 어디까지가 모델?
글쓴이 risa 작성시각 2013/07/19 09:59:33
댓글 : 8 추천 : 0 스크랩 : 0 조회수 : 9646   RSS
최근 아리쏭한 혼돈이 오고있습니다.

몇 달 전까지만 해도 

컨트롤러에서 액티브 레코드 사용이 불가능 하다고 생각

했습니다.

(CI 접하고 2년만에 깨달음)



그렇기에 저는 이렇게 모델을 구분 하여 사용했습니다.

model [해당 컨트롤러의 메인 모델]
codel [공용 모델 모드... 주로 액티브 레코드 단순 검색, 입력, 수정, 삭제]
sadel [공유 모델. 공유되서 사용될만한 쿼리문. 예 popup, ajx, 기타 공유될만한 것]

문제는 CI에서 직접 액티브 레코드 사용이 가능 하다는걸 알게 된 순간...

$this->codel->insert_one('table',$data); 

이럴 필요없이

$this->db->insert('table',$data); 

이러기 시작....


자원 소모 요소를 생각 해보면 codel 이라 하는 모델을 로드 해서 사용하는 것 보다 훨씬 유리합니다.

표현도 즉흥적이고요.


그러나 이게 맞는건지 참...

구분적으로는 컨트롤러에서 모델 없이 바로 쓰는거다 보니 깨름직 하긴 합니다.

물론 복잡한 쿼리문은 model 에 넣고서 관리 하지만 말이죠.

공통적으로 사용되는 단순 쿼리문은 그냥 바로 사용하는게 편합니다만... 모델에 규약 하지 않고 쓴다는건

매번 저항감이 생기네요.


뭐 PHP 라는놈 자체가 원래가 모델 이라는 개념이 없던 녀석이긴 하지만 말이죠.


여러분은 어떻게 생각 하시나요?

컨트롤러에서의 쿼리문 사용에 대해서?
 다음글 세션에 뒤통수 맞은 날... (2)
 이전글 작년에 기고한 수기 (11)
목록

댓글

이지포토 / 2013/07/19 11:28:42 / 추천 0
공동개발할땐 원칙을 철저히 준수하고
개인적으로 혼자만 유지보수하는건 솔찍히 모델까지 열기보다는 간단한 쿼리문은 직접 컨트롤러에서 처리합니다. 즉흥적으로..(간단한 셀렉트문)
그러나 적어도 join 문이 들어간 쿼리문은 모조리 모델에서 처리하죠.

중요한것은 남이 봤을때 일관성있고 알아보기 편한대로 코딩하는것이 답이 아닐까요?
oursong / 2013/07/19 12:04:49 / 추천 0
음. PHP를 전혀 모르는 제가 이런 멘트를 남겨도 좋은지 모르겠습니다.
저 같은 경우엔 C에 가까운게 PHP라서 쓰는데요.

전 처음엔 'MVC에 맞춰서 패스가 잡혀있으니 이리 쓰는갑다...' 했습니다.
그런데 작업하면서 메뉴얼보다, 시스템 폴더 내용물을 보는데... '어레?!' 했습니다.

매뉴얼에도 동작개념도가 있습니다만, 어플리케이션과 라이브러리를 제외하면 나머지는 매우 자유로우며,
php함수에 무지한 저 같은 사람들에겐 정말 친절한 프로세싱도 제공하고 있어서 CI를 이용하고 있습니다.

하지만 모처럼 체계가 있으니 체계를 따르는게 좋은데 컨트롤러는 되도록 페이지프로세싱에 주안점을 두는게 좋다고 봅니다.
하나의 모듈이 하나의 일을 완벽하게 처리하게 하는 것입니다.
모델에선 서버와 처리하는 관련 일을 하면 좋겠지요.

문젠 컨트롤러와 모델사이에 분배할 일이 붕 뜨는 경우가 있는데, 아마 보통 이걸 둘 중 한 곳에 배정해서 사용하실 것 같습니다.
저같은 경우엔 이런걸 case by case로 라이브러리에 시키는 편입니다.

이렇게하면
컨트롤러는 index to Application,
모델은 컨트롤러 to DB,
라이브러리는 컨트롤러 to 모델로 가는 처리기로 쓸 수 있게되고

소스의 가시성이나 시스템 파악도 빨라서 깔끔하고 좋더군요.
한대승(불의회상) / 2013/07/19 13:31:12 / 추천 0
CI의 가장 큰 특징중 하나인 느슨한 MVC를 경험 하셨군요.
리소스 소모량이나 코딩 속도, 미세하나마 실행속도등을 고려 한다면 컨트롤러에 직접 기술 해도 무방 하다고 생각 됩니다.

저 같은 경우 ajax용 컨트롤러의 경우는 view를 생략 하기도 하구요.

하지만 모델은 꼭 분리 하려고 합니다.
협업, 분업, 인수인계 그리고 재사용성을 생각 해서요.

느슨하다고 막 가져다 붙이게 되면, 프레임워크의 탈을 뒤집어 쓴 막코딩이 되거든요 ^^
변종원(웅파) / 2013/07/19 15:14:26 / 추천 0
급할땐 컨트롤러안에서 쓰기도 하는데(시간 나면 분리) 그외에는 무조건 모델 분리합니다.
이현석 / 2013/07/21 10:25:07 / 추천 0
 메뉴얼에
"CodeIgniter는 모델이 필요없도록 MVC를 매우 느슨하게 접근하였습니다. 만약 모델을 분리할 필요가 없거나, 모델을 따로 분리하는것이 쓸데없이 복잡도를 증가시킨다면, 컨트롤러와 뷰 파일만으로 프로그램을 만드실 수 있습니다. CodeIgniter는 여러분이 이미 가지고 있는 스크립트를 연동해서 사용하거나, 여러분의 기호에 맞게 시스템 코어라이브러리를 개발하여 쓸수도 있도록 했습니다."
라는 문구가 있어요 ㅎ
milosz / 2013/07/22 10:19:25 / 추천 0
적당히 커졌을 때 게을러하지 않고 재빨리 리팩토링 할 각오하고 임한다면 처음 개발은 좀 더럽게 가도 괜찮을 것 같아요 ㅎㅎ
변종원(웅파) / 2013/07/22 10:31:07 / 추천 0
milosz/ 대부분 리팩토링을 하지 못한다는게 함정이긴 하죠. ^^

커지면 사이트 자체를 다시 만드는 경우가 많으니...
검은빨대 / 2013/07/24 14:01:34 / 추천 0
흠 저같은 경우엔 이해하기 어려우 실 수도 있지만 시간이 지나면서 더욱 모호해 집니다.

기술을 위한 기술이 아닌 실제 서비스 레벨에서의 개발과 효율을 따지게 되다가 5년쯤 전부터

Window : MSSQL or mySQL and file system + C# (Webservice) + PHP + Jquey or DHTMLX
Unix or Linux : Oracle or mySQL and file system + Java(Web Service) + PHP +  quey or DHTMLX

이런 패턴으로 굳어지게 되었습니다.

뛰어난 아키텍쳐가 지원되는 대형 시스템은 물론 Spring 으로 갑니다만 (주로 일본인 아키텍쳐가 Spring 을 이용한 시스템 설계에는 꼼곰함으로 특 장점을 보여주더군요.)
그렇지 않은 경우는 비효율적인 자원관리와 개판 오분전인 산출물 문제로 야기되는 소스의 불정합성 때문이기도 하였습니다.

Window를 예로들면 
모델 : 데이터베이스의 Procedure를 이용하여 쿼리를 내부 생성하고 DB의 메모리 관리를 통해 항상 제대로된 성능을 보장받는다. (적어도 중고급 개발자가 개발한 것 보단 아직은 벤더사의 기술력을 더 믿을수 밖에 없습니다.) 또한 관련된 Procedure를 이용하여 C#을 이용한 웹서비스 레벨에서 데이터와의 트랜젝션, 미터링, 버전관리를 수행하고 라이브러리 참조를 하도록 시킵니다. 이 부분은 SOA 개념으로 생각하시고 각 웹서비스 별로 인증 및 미터링 등의 관리를 내부자원을 이용하여 상대적으로 무겁다는 SOAP 프로토콜을 사용하도록 합니다. 내부라서 무거운걸 못느끼겠더군요.

컨트롤러 : PHP는 컨트롤러의 개념을 확장한 GateWay 서버 형태로 개발합니다. 유연한 개발, 가벼운 CI 프레임웤으로 화면과 웹서비스간의 동적인 연결을 담당시킵니다. 또한 시스템의 부하가 생길경우 저렴한 서버의 물리적인 확장만으로도 부하를 몇시간안에 해소 가능합니다. 

View는 우리가 흔히 말하는 Script  덩어리로 만들어서 DHTMX로 보여줍니다. 모든 데이터는 GateWay를 통해서 송수신하고 인증,보안, 암호화처리등은 극히 초보적인 레벨로 움직입니다. 사실상 GateWay와 웹서비스간의 물리적인 망분리가 되기 때문입니다. 

상기 시스템은 경험상 철저하게 디자인과 비지니스로직, 데이터 구조가 분리됩니다.

유지보수가 용이하며, 어떠한 경우에도 전체 서비스를 내렸다가 올리는 경우는 없습니다.

웹서비스를 버전기준으로 관리하여 신버전 퍼블리싱 후에도 구버전 서비스 연계는 문제없습니다.

또한 개발 시간도 엄청나게 단축되었습니다. (숙련팀 조직후 약 75% 절감) 
예 ) 3.5억 SI 프로젝트 개발 2개월 (4명)

또한 성능도 향상 되었습니다.
HP  중고 (약 100만원짜리) 8대로 사용자 500만명 최번시 시간당 접속건수 *****를 문제없이 받아냈을뿐 아니라 IDC의 라인 점유 문제로 서버의 분산을 종용받기도 하였습니다.

말이 길어졌습니다만. 이것은 이거다, 저것은 저거다의 답은 어디에도 없는듯 합니다.
절대적인 명제는 효율은 중요한것이고 이것을 지키기 위해 프레임웤이 발전해 가고 있다는 게 아닐까 합니다. 
랭귀지는 도구이며 프레임웤은 서비스, 플랫폼은 서비스 + 부가서비스의 차원입니다.

시스템이 담당할 업무에 따라 어떻게 할 것인지를 정하시는게 정답이라고 생각합니다.
집을지을때 아파트와 빌라는 겉모양도 다르지만 속도 다르게 짓는다고 생각하시면 될듯합니다.