네트워크는 핑퐁이라고 생각하시면 쉬워요 

하나의 내용을 보내면 하나의 내용이 오죠

지금 인터넷의 경우 url을 보내면 내용들을 담은 html이 옵니다

그 사이에 뭔 url이 왔는지 처리를 어떻게 할껀지 뷰는 뭘 쓸껀지 디비처리를 할껀지 말껀지의 일련의 과정을 정형화 ? 시켜둔거라고 생각합니다.

모델-뷰-컨트롤러(Model–View–Controller, MVC)는 소프트웨어 공학에서 사용되는 소프트웨어 디자인 패턴이다. 이 패턴을 성공적으로 사용하면, 사용자 인터페이스로부터 비즈니스 로직을 분리하여 애플리케이션의 시각적 요소나 그 이면에서 실행되는 비즈니스 로직을 서로 영향 없이 쉽게 고칠 수 있는 애플리케이션을 만들 수 있다. MVC에서 모델은 애플리케이션의 정보(데이터)를 나타내며, 뷰는 텍스트, 체크박스 항목 등과 같은 사용자 인터페이스 요소를 나타내고, 컨트롤러는 데이터와 비즈니스 로직 사이의 상호동작을 관리한다.

디자인 패턴을 사수한테 배울때, 이렇게 말씀해주셨어요.

"다들 패턴이라고 하잖아. 이건 코딩 잘하는 놈들이 짜다보니 효율적으로 만들어지는 일련의 패턴들이 있더라~ 한거야. 그래서 그걸 '디자인패턴' 이라고 말하면서 너도나도 효율적인걸 정형화시켜 배운거지."

mvc도 패턴이잖아요, 맞춰서 코딩하면 효율적이고 코드를 알아보기 쉬우니까 사용하는게 아닐까 싶습니다^^  

  순수 jsp 로 게시판 목록을 보여주는 페이지를 만들어 보세요.

그리고 디자인을 수정해 보세요.

스프링에서 마찬가지로 게시판 목록 페이지를 만들어 본후 디자인을 수정해 보세요.

웹 디자인은 패션과 비슷해서 같은 옷만 입는 사람을 촌스럽게 생각하는 경향이 아주 높습니다.

그래서 자주 바꾸어 주어야 합니다.

디자인이 수시로 바꾸는 경우그것에 영향을 받지 않는것들을 분리하여 수정을 안하는 방법이 무엇일까?

순수 jsp 에서 고민해 보시고 그 길을 찾아보세요.

선배들은 그 길을 mvc 에서 찾은겁니다.

만약 그 길을 찾았다면 mvc 와 비교를 해 보고 이곳에서 알려주시기를 희망해 보며 마치겠습니다.

말 그대로 M(Model) V(View) C(Controller)을 분리하여 유지보수 및 확장성을 높이기 위해 만들어졌다고 생각합니다.

생겨난 원인에 대해 대략적인 예상을 해보면

1. 초창기에는 사람들이 Model, View, Controller 구분없이 한 소스 덩어리에(ex: 함수) 3가지 요소를

    섞어서 구현합니다. 처음에는 편합니다. 그냥 위에서 아래로 쭉 구현하면 되니깐요.

2. 요구사항이 바뀝니다. View의 수정이 필요한데 비즈니스 로직과 컨트롤 코드가 섞여 있어서 코드를

    읽기도 힘들뿐더러 View 코드를 수정하다가 비즈니스 로직과 컨트롤 코드에 영향을 끼쳐서 다른

    버그가 생깁니다.

3. 기능이 추가됩니다. 기능이 점점 추가될수록 더욱 거대한 View+Model+Controller 코드 덩어리가

    되어, 코드에서 내가 필요한 부분만 찾아내거나 확장하는 일이 점점 힘들어집니다.

4. 사람들은 고민합니다. 그리고 UI 프로그램에서 가장 핵심적인 덩어리는 Model, View, Controller

    이며, View <-> Controller <-> Model과 같은 관계로 연결될 수 있다는 사실을 발견합니다.

5. MVC 구조를 만들어냅니다.

    각각의 목적에 따라 코드가 분리되어 있어, 유지보수 및 확장성이 뛰어납니다.

    View 코드를 수정하다가 Model 코드를 실수로 수정할 일도 없습니다. 코드도 한층 읽기가 수월해집니다.

    이제 View를 수정하려면 View 컴포넌트만 기웃거리면 됩니다.

제 생각으로는 대략 위와 같은 이유가 아닐까합니다만.. 잘못되거나 부족한 부분은 다른 분들이 설명해주시리라 믿습니다. ㅎㅎ

여담인데 뷰템플릿도 여러개 써보시면 힘이 되요

저같은경우는 mustache 써보고 간결해서 편했어요

분리 한다는말보다 사실 더 중요한 본질을 말하면

각 layer 사이에 의존관계가 없다는 이야기 입니다.

웹으로 구축돼 있는 회원관리시스템이 있는데

이걸 앱으로도 출시하고 싶어요

그런데 layer간 의존성이 없고 관리 시스템의 정수(essence)가 잘 모델링 돼있다면 ( or POJO 스럽게?)

앱 껍데기만 만들면 되겠죠?

뭐 실제로는 어쩔지 몰라도요

학교를 가는데 짝수날은 100번 버스를

5의 배수인 날은 200번 버스를

소수인 날은 400번 버스를 탄다고 하면 

어떨때는 저거 어떨때는 이거 헷 갈리고 그러죠.

값의 데이터는 모델에서 가지고

뷰는 모델에서 주는데로 그려  

 하면 그리는게 문제인지 들고 있는 값이 문제인지 좀더 명확해지죠

MVC는 설계 패턴으로 어떻게 쓰는 것이 정답일 순 없고 활용의 추상화가 잘 된 패턴으로 생각됩니다.

서로 관계를 몰라도 되는 독립적인 레이어라는 것은 제 생각엔 그냥 방향입니다. 현실은 절대(99.9) 그럴 수 없습니다. 제가 생각하는 MVC는 다음과 같습니다.

M : 요청하는 api의 유형은 여러가지로 다를 수 있지만 비즈니스 모델은 재활용 되는 경우가 많습니다. 또한 비즈니스의 성공이나 실패로 묶여있는 트랜젝션 단위로 쓰는 경우가 많습니다.

V : 뷰는 담당자가 섞이는 영역이고, 디자이너와 일을 할 경우 비즈니스 로직과 디자인 업무를 분리하는 역할을 합니다.

C : 사용자 접근 계층이라고 보면 됩니다. 예를 들어 동일한 M 라이브러리를 가지고도 오픈 API용, 내부 API으로 쉽게 나눠서 서비스가 가능합니다.