MVC 패턴이 대체 왜 좋은거죠? > 자유게시판

자유게시판

MVC 패턴이 대체 왜 좋은거죠? 정보

MVC 패턴이 대체 왜 좋은거죠?

본문

정말 궁금한게 있습니다.
PHP 관련해 웹서핑하다 보면 Html과 php 코드를 섞어 쓰는 것을 짜파게티를 비유하면서 엄청 혐오하는 글을 많이 봅니다.
그러면서 html 과 php 코드를 분리하는 MVC 를 반드시 해야 하다고..

 

그런데 저는 반대로 처음에 html 안에 php 코드가 녹아 들어가는게 걸 보고 "오~ 좋네.." 했습니다.
예를들어 거래처를 관리하는 메뉴가 customer.php 라고 할때 어떤 버그가 발견되면 그냥 이 php 파일 안에 들어가서 고치면 간단한데 view에 가서 뭐 수정하고, controller 가서 뭐 수정하고.. 이런게 더 복잡하잖아요.
그런데 이 좋은 걸 자꾸 쓰지 말라고 하니.. ㅠ

 

이런 얘기를 하면 "규모가 커지면 MVC 가 답" 이라는 댓글이 꼭 달리는데 이것도 이해가 안됩니다.
프로젝트 규모가 커지고 파일 수가 많아질 수록 담당하는 화면마다 1개의 파일에서 다 처리하는게 효과적 아닐까요?
여기저기 왔다갔다 하지 말고 한 군데서  코드 고치면서 모양도 좀 바꾸고, 기능도 넣고.. 얼마나 좋아요.
규모가 크다는 것은 도대체 얼마나 큰 프로젝트를 말하는 것인지.

 

저도 윈도우용 프로그램은 오래 했지만 여기서도 상황이 비슷했습니다.
객체, 클라스로 쓰면 유지보수도 좋다고 해서 그렇게도 해봤는데 웬걸, 나중에 헤메는데 시간 다 씁니다.
제법 규모있는 ERP 도 작업해 보았지만 클라스 만들어 쓴 것들은 유지보수 제대로 못해서 나중에 다 포기한 반면 프로시저 방식으로 한 것들은 아직도 문제 있으면 10분이면 고쳐 줍니다.
물론 제 경우는 실력이 달려서 그런 것도 있겠지만,  쉽게 쓰자고 선택한 PHP 에서 완벽한 모델을 기획할 분이 과연 얼마나 될까요?

 

검색해 보니 PHP의 아버지 '라스무스'도 프레임워크 안쓰는게 좋다..고 했더군요.
그냥 창조주가 PHP 세상을 창조하면서 "이렇게 써라.." 했으면 "고맙습니다." 하고 쓰는게 정답 아닐까요?...ㅋ

 

저는 아무래도 객체, 클래스, 클로저.. 뭐 이런 개념들은 개발자가 몸 값 올리려고 만든 것 같은 의심이..
마치 시골 깡촌 마을에 서울 사람이 이사 와서 "여러분 앞으로 영어 못하면 나중에 굶어 죽어요.." 라고 해서 다 울면서 과외비 내고 영어공부하는 것 같은..?

 

MVC, 객체지향 찬양하시는 분들에게 조용하게 묻고 싶습니다.
"솔직히 마음 속으로는 예전 초기 방식이 더 좋다고 생각하지 않나요?"
솔직하게 얘기 좀 해 주세요.  저 그냥 html, php 맘대로 섞어 써도 되죠?.ㅎ
(아니어도 그렇다고 해 주길 바라고 있습니다)

 

P.S
제가 PHP 에서 마음에 안드는 점은 함수가 너무 많아요.
딱 100 개만 남겨두고 다 없애 버렸으면 좋겠습니다.  그러면 어떤 걸 쓸까 하는 고민도 없을텐데..
없으면 없는 대로 다 필요하면 만들어 쓰게 되거든요.  지금 거의 1,000 개는 되는 것 같네요..
 

추천
3

베스트댓글

혼자 하는 거면 MVC 필요성 없을 수도 있습니다.
대규모 인원이 개발하면 MVC가 필요할 수 있습니다.

MVC나 객체지향에 의문을 묻는 사람들은 대게 혼자 개발하거나
다른 서드파티를 잘 안 써본 사람일 겁니다.
M 모델 (데이터들)
V (view)화면
C 컨트롤러 (url 주소구성)
인데요

말씀대로 화면이랑 데이터 불러오는 곳이 같이 있으면
해당화면을 바로 고치면됩니다

그런데요 MVC 패턴이 좋은점은 이겁니다.
1.다른화면인데 같은 데이터를 불러올때
  데이터구성을 한곳에서 하기때문에 화면에 따라 재작성할것이 줄어듭니다.
  코드의 중복도 줄어들죠

2. api 를 뽑기가 쉽다
  화면과 데이터가 분리되어있기 때문에 단순히 웹페이지를 제작하는게 아닌
  앱같은 경우 데이터만 전송하게됩니다.
  이럴떄 MVC로 되어있다면 기존 컨트롤러를 이용해서 앱에서 데이터를 불러오기 쉽죠
  리액트나 / 뷰를 붙여하 할때도 마찬가지입니다.

3. 데이터들 테스트
  물론 화면도 테스트해야됩니다만
  DB에서 가져온값들 함수라던지 그런걸 따로 테스트할경우가 있습니다.
  예) php 버전 변경, 함수 수정 등등
  그 쪽만 자동화된 테스트 코드 돌리면 됩니다(읽기/쓰기 정도만있는 게시판에서는 크게 할일      없기 도합니다.)
  ERP나 쇼핑몰같이 돈을 다룬다면 테스트하는 편이 좋죠
 

요점은 분리를 해야 상황이 바뀔때 기존것을 활용하고 변경을 최소화 시킬수 있는겁니다.

댓글 22개

혼자 하는 거면 MVC 필요성 없을 수도 있습니다.
대규모 인원이 개발하면 MVC가 필요할 수 있습니다.

MVC나 객체지향에 의문을 묻는 사람들은 대게 혼자 개발하거나
다른 서드파티를 잘 안 써본 사람일 겁니다.
회사가 커지면 어떤 식으로든 체계가 필요합니다.

이해할 필요가 없거나 이해를 못 하시면 그냥 편한대로 하시면 됩니다.
좋고 나쁜게 아니라 그냥 약속 같은거라고 보시면 되요.
같이 해도 MVC 불편한 경우 많아요 ㅋㅋㅋ.

솔직히 말하자면 제가 느끼기엔 MVC안에도 다양한 형태들로 구현을 할 수 있어요.

java 고급 책 보시면 나오는데, 이렇다/저렇다/좋다/나쁘다 해놓고, 항상 결론이
고려해볼만하다에요.

상황에 따라, 업체에 따라, 아니면 상사에 따라서도, 같이 일하는 분들에 따라서도, MVC가 좋은 경우가 있고, 그냥 안 좋은 경우도 있습니다.

저 같은 경우는 그냥 맞춰줍니다 대부분...

MVC 프로젝트가 좋은게 아닌 대부분 그 형태로 많이 배웠기 때문에, 그렇게 하게 되는거죠.
요즘 많이들 쓰시는 react.js는 제가 프로젝트를 해보진 않았지만, 스터디는 혼자 했던기억이 나서 말씀드리는건데, MVC패턴이 아닌, FLUX 패턴으로 많이 하는 걸로 기억하고 있어요.

신입 때 심심풀이로 했던 블로그에 내용이 남아있네요... (블로그를 딱 1년정도 했던걸로 기억하네요.)
https://blog.naver.com/canghun13/221118679151
혼자하시는거면 그렇게 하셔도 아무도 뭐라안하죠
근데 회사에서 분업하는거면 MVC패턴을 따라가는게 맞다고 봅니다

저도 코딩 초짜일때 왜 굳이 나눠야하지??라고했는데 지금은 왜 안나누지 불편하게란 생각만 듭니다
한곳에 다들어가면서 생기는 장점이있을순 있지만 유지보수에 상당한 어려움이 따른다는걸 이제는 알거든요...

진짜 MVC로 나눠놓으면 퍼블리셔도 편하고 개발자도 편합니다
일의 분업화가 가능하니까 MVC패턴을 추천하는거에요

다시말하면 혼자하면 뭘 하던 자기가 편한대로 하면 됩니다
근데 분업이면 퍼블리싱과 개발이 나눠져있다면 분리하는게 나아요

전 근데 이제 혼자해도 한곳에 다 넣으니까 너무 불편해서 안되겠드라구요 ㅋㅋ 무조건 나눕니다 그래야 보기도 좋아요
뷰에는 출력할 데이터만 쏴주면 되지 그 데이터를 출력하기 위한 계산식이 들어갈 필요는 절대없다고 생각되거든요
칼이 여러종류 있듯이 상황에 맞는 패턴들이 여러개 있죠.
가정용 칼, 중식당용 칼등이 있듯이.

요즘 웹쪽에 인기를 끄는 것이 MVC패턴이구요. 최근 윈도우용 프로그램쪽은 wpf등은 MVVM패턴이 인기입니다.

저도 예전에 classic asp나 php할때는 구분없이 한파일로 했었구요. 그때는 대체적으로 그렇게 했습니다.

지금 그때의 일부 사이트들 수정할려고 보면 결합도가 너무 강해서 코드 분리가 어렵고 힘들게 느껴집니다.

mvc로 분리하면 코드테스트하기에도 좋구요.
한개 파일내에서도 MVC를 구분해서 코딩 하면, MVC를 쓸 필요가 없습니다만,,,
보통 M(Model) 부분이 공통 영역이라서 파일 분리가 발생하는것이구요.

VC 형태로 코딩 되는경우에 모델이 아닌 쿼리와 resultset 으로 모델을 대체하는 경우는 한개 파일에서 구현이 가능해집니다.
코드를 깔끔하고 심플하게 VC형태로 구현하게 되면, 문제가 없습니다만,,,,,,,

님이 만들어놓은 그 VC 형태를 다른 사람이 만지면, 개판(???)을 만들어두게 됩니다. 왜냐하면 개발자마다 생각의 차이가 있기 때문이죠. 실력이 낮을수록 경험이 낮을수록 이게 더 심합니다..

결국 어떤 사람이 만든 코드는 만든 사람만 수정하는 상황이 생기는데, 이러면 시너지가 줄어들게 되고, 업무불화로 회사 문닫는 상황까지 만들어집니다.

MVC를 강조하는 이유는,, 설계 철학보다는 프로젝트의 개발/운영 때문일수 있습니다.


돌아만 가는 코드를 만드는건,,,, 뭘로 하든 상관없습니다. 심지어 빠르게 만들면 오히려 더 대접받습니다.
혼자만 만들어서 혼자만 서비스하는 코드야 돌아만 가면 되는거죠.


그누보드야 원래 MVC가 아니니, 그누보드를 MVC로 뜯어고치는 노력보다는
VC 라도 잘 지키는 코드를 만드시는걸 추천드립니다.
mysql result 를 view 영역에서 for 루프 돌리는것은 그만 봤으면 좋겠습니다.
데이타에 대한 가공은 상단 코드에서 다 끝내놓고,,, view(html,css) 영역에선 데이타 출력만,,,

MVC 보다,,,,, 코드를 easy하게, 심플하게 짜는 노력을 하다보면,,,
MVC 와 Modern PHP로 넘어가게 될거에요...
이미 다른 개발자들은 다 경험한걸 철학적으로 구현한게 디자인패턴과 MVC입니다.
저도 윈도우프로그램부터 개발을 시작했습니다. 도레미님 말씀에 어느 정도 공감은 합니다.
모두가 mvc를 좋다고 할 때, 다른 대안이 있다는 의견으로 이해하고 있습니다.

mvc 방법론도 사람이 만든거라 완벽할 수 없습니다.
mvc의 단점을 발견하고 고민을 해야지 학문적인 발전이 생깁니다. 이러한 방법론으로 개발을 하면서 어떤 단점이 있고 어떤 장점이 있는지 명확하게 찾을 능력이 있어야지.. 무조건 이게 좋다라는 식으로 무비판적으로 사용을하면 결국 자기 자신한테도 안좋습니다.

전 개발언어를 공부를 하면서 창시자의 개발 철학이 어떠한지부터 봅니다.
철학을 먼저 알고 사용을 하게되면 이런게 좋고 이런게 나쁘구나라는 것을 깨닫습니다.

함수가 너무 많다라는 것은 동의하지는 못합니다.
각 분야에 필요한 함수가 있을 수 있으므로, 성급하게 생각해서 함수는 이정도만 있어야지 재단하는 것은 아니라고 생각합니다..
저도 라스무스의 개발철학을 좋아합니다.
"나는 프로그래밍은 싫어하지만 문제를 해결하는 것은 좋아한다..."
php 자체제작 MVC 쓰다가, 그누보드로 첨 딱 넘어왔을때 첫인상은 속으로 조금 실망했으나, 지금은 너무나도 만족하며 쓰고 있습니다. 다만 한계는 보이지만 지금 주어진일에선 전혀 문제될것 없고, 생산성 또한 다른것에 비할바 없이 빠르고 만족스럽게 결과물이 나옵니다. 근데 요즘엔 mvc 아니고 mvvm 아닌가요? ㅎㅎㅎ 디자인 + 프론트 엔드개발 + 백엔드개발 이런 개발방식이 유행? 이잖아요. ㅋㅋㅋㅋㅋ

자바 스프링 프레임워크(전자정부 프레임워크)로 개발된 중대형 프로젝트들이 워낙 많다보니 mvc로 개발된 것들이 많기에 수요와 공급의 원리로, 생태계가 제일루 거대하긴 하죠.
오늘 답글들 중에서 가장 마음에 듭니다...ㅎ
얼마 안되는 내 포인트 다 드리고 싶은...

앞으로 10~20년 뒤에는 틀림없이 JPA 패턴이 유행할 것으로 예측합니다.
Java Pattern Against
그리고 우리들은 이 약자를 짜파게티로 부르겠지요.

그누보드가 워드프레스를 제치고 세계 1등만 하면 이 방식이 최고라고 다 돌아 오리라 확신합니다.
그러게요

새로운것은 그 나름대로 이전것에 대한 문제점을 보완하는 방식으로 나왔는데
그 장점은 무시하고 자기 식견만 강조하고 결국 자기가 듣고 싶은 것만 듣겠다고 보이네요

그럴거면 PHP 이전에 CGI 하던 사람도 똑같이 말할수 있습니다.
CGI 를 조금만 튜닝하면 PHP 정도의 성능 나오는데 뭘 굳이 새로운 방식을 배우냐 하는거죠 ㅎㅎ
ㅎㅎ
이렇게 억지 춘향식으로 질문하지 않으면 다 MVC 충성파 답변만 달리거든요.. 그래서..ㅎ
그래도 오늘은 어느 정도 좌우 균형이 잡힌 답변들이 왔네요.
리액트도 마찬가지로 크게보면 코드와 jsx를 같이 쓰는 컴포넌트 형태의 코딩방식인데
요즘에는 이런 같은 성격의 컴포넌트는 한곳에 관리하는 쪽으로 js쪽에서는 많이 사용하더라구요.

예전에 css는 꼭 분리하고 인라인스타일링은 안좋은것이라 말했고 이게 정석처럼 이어져 내려왔지만
Tailwind css 처럼 인라인 방식의 코딩방식이 분리하는 방법보다 생성선과 속도측면에서 30%는 더 빠른것같더라구요.

함수형 프로그래밍 방식에 익숙해져갈때 flutter 하느라 dart 언어의 oop 방식으로 코딩을 하는데
oop도 나름 장점이있고 매력있긴한데
냉정하게 직관적인 방식은 oop보다는 절차지향적인게 대부분 사람들에게는  초반에 받아들이기가 쉬운것같습니다.
oop는 한번의 생각의 전환이 필요하다랄까 제가 생각하는 느낌은 그런 느낌이더라구요.

저는 타입스크립트와 tailwind css 가 개인적으로 가장 쓰면서 만족도가 높은 언어중에 하나라 생각이 드네요.
말씀하신데로 저도 각각의 성격을 컴포넌트단위로 나누고 그안에 모든코드를 작성하는걸 선호하긴 합니다요.

결론은 next js , tailwind css , flutter 짱 뭔가 신세계임
M 모델 (데이터들)
V (view)화면
C 컨트롤러 (url 주소구성)
인데요

말씀대로 화면이랑 데이터 불러오는 곳이 같이 있으면
해당화면을 바로 고치면됩니다

그런데요 MVC 패턴이 좋은점은 이겁니다.
1.다른화면인데 같은 데이터를 불러올때
  데이터구성을 한곳에서 하기때문에 화면에 따라 재작성할것이 줄어듭니다.
  코드의 중복도 줄어들죠

2. api 를 뽑기가 쉽다
  화면과 데이터가 분리되어있기 때문에 단순히 웹페이지를 제작하는게 아닌
  앱같은 경우 데이터만 전송하게됩니다.
  이럴떄 MVC로 되어있다면 기존 컨트롤러를 이용해서 앱에서 데이터를 불러오기 쉽죠
  리액트나 / 뷰를 붙여하 할때도 마찬가지입니다.

3. 데이터들 테스트
  물론 화면도 테스트해야됩니다만
  DB에서 가져온값들 함수라던지 그런걸 따로 테스트할경우가 있습니다.
  예) php 버전 변경, 함수 수정 등등
  그 쪽만 자동화된 테스트 코드 돌리면 됩니다(읽기/쓰기 정도만있는 게시판에서는 크게 할일      없기 도합니다.)
  ERP나 쇼핑몰같이 돈을 다룬다면 테스트하는 편이 좋죠
 

요점은 분리를 해야 상황이 바뀔때 기존것을 활용하고 변경을 최소화 시킬수 있는겁니다.
기본적인 개발 기본기의 차이입니다.

순차지향적인 코드를 작성하는 분이어도, 유지보수 및 협업에 진짜 최적화 돼어서 코딩하시는 분도있는가 하면, MVC로 코딩하여도 도저히 유지보수도 안돼고 협업도 못할정도의 분도 있습니다.

웹에서 MVC 노래를 부르는 이유는, 최소한 MVC 에 대한 이해가 있고 그것을 재대로 구현이 가능한 사람과 협업을 하게 됀다면, 협업 개발자의 최소한의 수준을 기대 할 수 있기 때문입니다.

최신 웹 트랜드로 이야기를 하자면, 과거 코드이그나이터가 유행을 하였었는데, 그 이유가 MVC + 유연한 구조 였습니다. 하지만, 코드이그나이터는 유연함을 추구하다보니 MVC 프레임워크임에도 순차지향적인 느낌이 드는 코딩을 하는 프로그래머들이 많았습니다. MVC 를 하는 이유가 코드의 재사용인데, 1회성 class 와 function 을 남발하면서 이것이야 말로 MVC다! 하는 분들이 많았죠.

그러다보니 나온게 유연함을 포기하고, 많은것을 프레임워크가 관리해서 조금이라도 메뉴얼 코딩에서 어긋나면 오류 뱉어버리는 라라벨이 나왔습니다. 라라벨이 나오고나서 찬양론자가 늘어난 이유는 CI에서 경험했던 MVC 아닌 MVC 프로그래머들과의 결별을 하고 진짜 MVC 를 사용하는 수준급(?)의 개발자와 협업이 가능하다는 보장(?)이 가능했기 때문에 많이들 넘어가고 찬양하고 있습니다.

개발자가 개인 작업이라도 꼭 MVC 로 개발을 해야 할 필요는 없지만, MVC 패턴이 왜 생겼고, 현재 MVC 패턴이 왜 우세한지에 대한 이해를 하시면 개발 커리어상 나쁘지는 않습니다.
MVC에서 더 웹 어플리케이션에 맞춘 패턴도 있습니다.

https://en.wikipedia.org/wiki/Action%E2%80%93domain%E2%80%93responder

저는 Action Domain Responder 패턴이 가장 적합하더라구요.
오~
저 처럼 단세포 적인 생각이 아닌 제대로 다르게 생각하는 사람들이 많군요.
저도 지금 정신을 잊지 말고 공부해야 겠네요.
전체 195,056 |RSS
자유게시판 내용 검색

회원로그인

진행중 포인트경매

  1. 참여0 회 시작24.03.28 11:15 종료24.04.04 11:15
(주)에스아이알소프트 / 대표:홍석명 / (06211) 서울특별시 강남구 역삼동 707-34 한신인터밸리24 서관 1404호 / E-Mail: admin@sir.kr
사업자등록번호: 217-81-36347 / 통신판매업신고번호:2014-서울강남-02098호 / 개인정보보호책임자:김민섭(minsup@sir.kr)
© SIRSOFT