출처 : http://hoons.kr/board.aspx?Name=asptip&BoardIdx=27769&Page=1&Mode=2
MVC패턴은 아주 오래전부터 사용하던 기법입니다.
Model View Controller...
대표적으로 MFC의 윈도어플 위저드가 MVC 패턴으로 생성해주고 있죠.
JAVA진영에서는 JSP 자체가 서블릿이기 때문에 서블릿 자체를 콘트롤러를 사용할 수 있어서 프래임워크없이 MVC로 웹어플리케이션 작성이 가능했습니다. 이렇게 작성하는 방법을 Model 2라고 부르지요. 어디서 생겨난 용어인지는 잘 모르겠습니다.
개념은 간단합니다. 요청을 받는 서블릿이 URI를 해석하여 Model 클래스의 메소드를 실행해 반환된 값을 View에서 보여준다... 헌데 요청하나에 서블릿이 하나가 기본이다 보니... 요청마다 서블릿이 있어야 --; 결국 유지보수에 문제점이..
그래서 매핑을 통해 하나의 콘트롤러에 몰아버릴 수도 있으나... 이경우
콘트롤러가 너무 복잡해지는게 문제지요. if문 많이 사용되겠지요.
스트럿츠라는 스타가 나오면서 자동화되어 많이 많이들 사용하게 되었지요.
최근에는 Spring MVC를 많이 사용하는 추세입니다.
MVC의 개념은 명확합니다.
1. 모든 비지니스 로직은 Model에서 다룬다.
2. View는 보여주기만 하자.
3. 콘트롤러는 이 둘을 연결하는 역할을 한다.
웹어플리케이션에 대한 이야기이니... Model은 대게의 경우 DB 핸들링이 되겠네요. 흔히 이야기하는 CRUD 4가지 액션이 되겠네요. 유효성 검사 역시 Model 에서 하는게 좋습니다.
이기능을 하는 클래스를 하나 만들어 두는 거지요. ADO/LINQ/DB 프래임워크... 무엇이든 관계 없습니다...
3.5이니 LINQ가 좋지 않을까 생각해보네요.
LINQ 자체를 쓰는것도 방법일테구요... 전통적으로 리파지터리 인터페이스와 클래스를 하나 더 만들어서 추후를 대비하는 기법을 많이 씁니다.
여튼, 모델은 끝났군요. 이 모델은 MVC 패턴 뿐만 아니라... ASP.NET 본래의 방법에서도 써먹기 좋겠지요.
아래처럼 써먹겠지요.
IBbsRepository bbsRepository = new BbsLinqRepository();
BbsArticle bbsArticle = new BbsArtcel();
bbsArticle.title = request["title"]
....
....
bbsRepository.add(bbsArtice);
bbsRepository.commit();
뭐 이런식으로 사용하면 되겠지요.
객체지향과 담쌓으신 분들을 위해 왜 라파지터리에 인터페이스가 필요할까도 한번 생각해 보면 좋을 것 같습니다.
말씀드렸다시피 ADO를 사용한 녀석이 될수도 있고 LINQ를 사용한 녀석이 될수도 있고 혹은 다른 프래임워크를 쓴 녀석이 될 수도 있으니... 인터페이스로 규약을 만들어 놓으면 바꿔치기가 쉽겠지요. 인터페이스는 바로 규약인 것입니다.^^;
위에서 작성한 코드는 MVC에서는 Controller에 들어가는 내용이 되는거지요.
모델이 완전히 분리가 된것 같네요.^^; - 사실 분리가 안됐습니다. new를 써버려서 강하게 결합되어 있지용.... 이 문제는 다음에 다시 이야기 해봐용, 이걸 해결하기 위한 기법이 바로 IoC/DI기법입니다-
IBbsRepository bbsRepository = new BbsLinqRepository();
bbsArticle = bbsRepository.getArticle(request["articleid"]);
게시글 상세 보기를 수행하는 콘트롤러의 한부분이 위와 같다고 하지요.
일단 bbsArticle이라는 엔티티 클래스에 내용이 들어가겠네요.
여기서 콘트롤러의 역할이 끝나면 안되지요. View로 전달을 해줘야겠지요.
return View("read",bbsArtice);
ASP.NET MVC는 위처럼 View로 보냅니다.
read.aspx 파일이 뷰가 되고, view에서 bbsArticle을 사용하도록 토스해주고 있네요.
read.aspx 파일에서 제목 : <%=Mode.title%> 이런식으로 사용하면 되는거지요.
MVC에서는 콘트롤러가 가장 중요한 녀석이지요. 중심에 서서 모델을 실행하고 결과를 다시 View에 전달하는 가장 핵심이 되는 녀석이죠.
ASP.NET MVC는 기본적으로 URL 라우팅이라는 기법을 통해 콘트롤러(하나의 클래스로 정의됩니다.)와 콘트롤러 클래스 내부의 메서드(액션메서드라고 합니다.)를 선택하게 됩니다.
기본적으로
/bbs/read/3
이런 요청이 들어오면 bbsController 클래스의 read 메서드를 실행하고 매개변수(id라고 설정했다고 가정)에 3을 넘기게 되지요.물론 위의 URL 패턴은 사용자 맘대로 변경 가능합니다.
RubyOnRails와 비슷한 면이 많습니다. 사실 비교 해보면... RoR의 영향을 엄청나게 받았다는 것을 알 수 있는 부분이 많지요. 이부분도 다음에 이야기해 보아요.
위 URL은 콘트롤러가 bbs 이며 메서드가 read 다. 그리고 매개변수는 3이다.
입니다. 콘트롤러가 bbs인데 bbsController의 인스턴스가 생성되는 이유는 규칙이기 때문입니다.
콘트롤러 명명 규칙이 xxxController인거지요. 이렇게 하자고 약속을 해버린 것입니다. path역시도 /Controller에 있죠.
View의 Path는 /View지요. 위 메소드의 기본 뷰는 /view/bbs/read.aspx 입니다. 이것 역시도 약속입니다. 강제하는 것이지요. 물론 바꿀 수도 있습니다만... 기본적으로 이렇게 하자고 권장을 하고 있습니다.
이런부분들이 RubyOnRails의 가장 큰 개념이기도 합니다. 설정보다는 규약이 프로그램하기 쉽다... 라는... 한마디로 응용보다는 암기가 더 쉽다...라는 거지요 ^^;
이제 명확히 분리가 됐네요.
MODEL은 아예 다른 DLL 파일로 만들어버렸으니 완전히 분리가 되어 있고...
CONTROLLER는 비지니스 로직 안들어가고 MODEL에서 정보만 가져와서 VIEW에 넘겨줬으니...
이제 남은건 VIEW가 보여주기만 하면 되겠네요.
헌데... 기존 ASP.NET 개발자분들이 헷깔리는 게 VIEW일꺼라 생각해 봅니다.
기존 ASPX와 전혀 다르다는 거지요. 기존 ASPX처럼 서버콘트롤을 사용하지도 못합니다.
그러다 보니 ASP.NET의 상징인 포스트백 사용도 안됩니다.
마술같은 ASP.NET Ajax 사용도 안됩니다... 뭐 이런 경우가? ㅋㅋ
MS는 ASP.NET을 왜 웹과 어울릴수 없는 포스트백 방식(이벤트드리븐)으로 만들었을까요?
생산성이죠. 예전 VB같은 방식으로 웹어플리케이션도 개발해 봐라~ 해서 나온거죠.
물론 그 방식이 상당히 웹과 안어울리는 방식같이 보이긴 하지만...요... 생산성 측면에서는 따라올 솔루션이 없죠.
ASPX 파일에 서버 콘트롤 올려다 놓고 load이벤트에서 DB 조회해서 바인딩 시키면 끝~~~;
코드도 워낙 짧아서 분리할 필요도 없고.. 페이지 하나 만드는데 1분이면 충분~~~; 생각대로 하면 됐죠.
2.0부터는 아예 코드가 필요없이 바인딩시킬수 있을 정도로 만들어 놨지요.
ASP.NET의 가장 큰 장점은 생산성인데... 그걸 버리고 왜 MVC로 가야 하느냐???
기존 ASP.NET 개발자들은 딜레마에 빠지게 됩니다.
그럼 왜 MVC를 써야할까요?
흔히 유지보수 이야기를 많이 합니다.
분리되어 있으니, 유지보수가 쉽고 명쾌하다는 거지요. 기존의 ASP.NET은 유지보수가 어렵냐?
사실 그렇지도 않습니다.^^; 개인적으로는 오히려 ASP.NET이 유지보수가 더 쉽지 않냐라는 생각입니다.
어짜피 대규모 프로젝트라는 건 말이죠... 작은 요소요소가 많아져서 대규모 프로젝트가 되는거지 하나의 요소가 엄청 커서 대규모프로젝트 혹은 엔터프라이즈급 이런 용어를 쓰는 건 아니거든요.
MVC가 웹어플리케이션에 상당히 잘 맞다는게 첫번째 이유같습니다.
요청->변경/조회->응답 이라는 웹어플리케이션 구조와 상당히 잘 맞는 다는거지요
콘트롤러->모델->뷰 그럴듯하죠?
그리고 N-tire기법이 활용될 수 밖에 없는 웹어플리케이션과 MVC 개념역시 잘 맞아떨어지고 있네요.
또한 MVC의 기본 원칙이 분리(의존성분리)이기 때문에 테스트주도개발이 가능하다는 거지요.
테스트 주도 개발에 대한 이슈는 다음시간에 이야기할께요. MVC를 쓰는 가장 큰 이유입니다.
그리고 한가지 더, 깔끔한 URL을 들수가 있겠네요. 검색엔진이 수집하기 쉽겠죠. 그리고 사용자에게도 친화적일테구요.
ASP.NET의 포스트백관련 기능이 안되는거지... 마스터 페이지, 인증, 국제화같은 기능은 여전히 지원되고 있구요.
예전부터 웹을 접하신 분들이라면 ASP.NET의 문제점을 서버콘트롤이라고생각할 것 같습니다.
자동화해놓은 것까지는 좋은데...
웹과 어울리기 힘든 이벤트 드리븐 방식을 채용했기 때문에 서버콘트롤이라는 개념을 도입한 거지요.
HTTP는 상태유지가 안되는 프로토콜이기 때문에.
버튼을 눌렀을 때 혹은 특정 이벤트를 발생시켰을 때 페이지 단위로 상태가 유지되어야 하는데요. 그래서ViewState라는 개념 만들게 되지요. 헌데 이게 좀 크다는 문제가 발생하게 되었지요.
서버콘트롤 디자인을 개발자가 하는 문제도 발생하게 되지요. 코더들이 알수가 없거든요^^; css 적용하기 좀 그런 구조지요. HTML이 실제 렌더링 되기 전까지 서버 콘트롤 코드만 보고는 이게 어찌 렌더링되려는지 알수 없다는거지요. 기존의 웹개발자들이 가장 어이없어하는 부분일것 같습니다. 또한 서버 콘트롤이 지원하지 않는 디자인 형태를 만들기 위해서는 어쩔 수 없이 스파게티코드가 생산될수 밖에 없구요.
ASP.NET은 생산성이 1차 목표였기 때문에 사실 개발자들이 모델부분만 따로 분리해서 개발하지 않죠. 코드비하인드기법을 활용하는 정도가 전부이지 않나 싶습니다. 그래서 모델/뷰가 너무나도 끈끈하게 한뭉탱이가 되어 있죠.
이말은 Nunit등과 같은 자동화 테스트 툴을 이용할 수 없다는 거지요.
대략 정리해 보자면....
빨리개발하고 싶다면, 데이타바인딩의 편리성을 사용하고 싶다면...
기존 ASP.NET을...
테스트주도 개발 방식, 확장성, 괜찮은 URL, 어라... 내가 개발자구나? 라고 느끼고 싶다면(?) MVC를 사용하면 될 것 같군요.
사실 MVC라는 것도 처음 개념만 잡히고 설정만 제대로 해놓으면... 쉽습니다. ASP.NET MVC는 비주얼 스튜디오가 유용한 템플릿을 많이 제공해주기 때문에 코드 노가다를 많이 줄일 수도 있습니다.
그리고 서버콘트롤에 거부감을 가지고 계시는 저같은 개발자분들에게는 MVC를 더 추천해드리고 싶네요.^^; 작은 프로젝트라 하더라도 말이죠.
MVC는 웹환경과 상당히 잘 맞다는 걸 다시한번 말씀드리고 싶군요.
다만 그리드를 통해 데이타바인딩이 주류인 프로젝트들은... 그냥 ASP.NET으로 금방 끝내버리시기 바랍니다. 그리드콘트롤하나 놓고 반인딩하면 끝나는데... 모델따로 만들고, 생소한 VIEW 메소드들 보면서... 고생할 필요는 없을 것 같네요.
보통 관리모드 만드는 것은 역시나... 제 생각에는 기존 방식이 훨씬 좋지 않나 싶습니다. 인트라넷도 마찮가지구요.
검색엔진 신경 쓸 필요도 없고, 사용자가 그닥 많지 않으니 사이즈 신경 쓸 필요도 없고...
신경쓸 게 없으니 말이죠. 하루면 될 일을 3일동안 할필요는 없겠지요.
끝내기 전에... 한말씀...
사용자는 MVC를 쓰든 기존 ASPX든, JAVA인지 PHP인지 전혀 신경 안쓴다는거죠.
개발자 입장에서는... 최대한 유지보수 편하게 만들어 놔야지요.
변경사항이 있을면 최소한의 수정만으로 바로 반영될 수 있도록 말이죠.
모델은 역시나 분리하는게 좋습니다. 아예 DLL을 따로 빼버리는게 가장 현명합니다.
물리적인 분리를 의미하니깐요.
그리고 인터페이스를 잘 활용하시면 좋습니다. 규약을 만들어 놓고 시작하는 거죠.
객체지향언어를 쓰면 인터페이스는 당연히 써줘야 예의지요.
인터페이스형으로 실제 클래스 인스턴스를 생성한다는 것 자체가... (인페이스의 변경이 없다면)
클래스를 사용하는 쪽의 코드 수정은 필요없다라는 걸 이야기하는 거니깐요.
실제 인스턴스화된 클래스 내용만 수정하면 되겠지요.
역시 A 클래스를 수정하지 않고 수정량이 많아서 B 클래스를 만들었다고 치죠.(인터페이스는 같은...)
그러면.. 이 클래스를 사용하는 클래스(콘트롤러)도 당연히 코드가 수정되어야 겠죠? 클래스명이 다를테니... IXxxx xxx = new xxx1(); -> IXxxx xxx = new xxx2(); 이런식으로요. 그래서 나오게 되죠. 스프링 프레임워크/ 윈저캐슬 같은 IoC 프래임워크가 말이죠.
Ioc는 new를 쓰지 않음으로써 최대한 결합을 느슨하게 해주는게 목표입니다.
Dependency Injection, 한국말로 의존성 주입..
구체적으로 스프링같은 프래임워크가 객체를 관리하며(자체는 싱글톤으로 동작), 필요한 객체에 인스턴스를 넣어준다는 거지요.
프래임워크가 어떤 객체를 관리하냐는 XML에 설정하는 방법을 쓰지요.
또 한가지... 말씀드릴부분이 있군요. 기존 ASP를 개발하셨던 분들의 가장 큰 고민은...
Request로 넘어온 값들을 어떻게 자동화할 수 없겠느냐 하는 것이었습니다.
게시글을 저장하는 시나리오를 생각해 보겠습니다.
title, writer, content, image 등의 폼이 있고, 같은 이름의 컬럼이 있다고 할때...
dim title, writer, content, image
title = request("title")
writer = request("writer")
content = request ("cotent")
image = request("image") '파일이겠지만 그냥.. 간단하게..
if (len(trim(title)) < 2) then
JsAlertAndHistroyBack("제목은 2자리 이상이어야 합니다.")
response.end()
end if
'.... 유효성 검사계속
insert bbs(title, writer,content,image) values(위의변수들...)
이런 방법을 사용했죠.
유효성 검사야... 뭐... 어쩔 수 없는 부분이라 치더라도...
request(xxx) 이걸 변수와 매핑하는 건... 노가다의 극치였죠.
방법이 없는 것은 아닙니다. 딕셔너리 객체를 만들어 request.form 객체를 넣어버리고 자동으로 sql 문을 만들 수 있는 함수를 만들어 줄 수 있습니다. 고급기법이군요.
여튼...
특정 변수에 요청에서 온 값을 자동으로 매핑할 수 있는 방법을 MVC에서는 자동으로 지원해주고 있습니다.
데이타 바인딩이라고 하지요.
액션메서드에 매개변수명을 폼변수명과 똑같이 선언하면 매개변수에 자동으로 할당됩니다.
혹은 매개변수에 엔티티클래스를 넣어주면 엔티티클래스의 프로퍼티명과 폼네임이 같을 경우 자동으로 프로퍼티에 넣어 주기도 합니다. 원하는 녀석만 선택적으로 필터링할 수도 있습니다.
이런 기술을 프래임워크가 지원해주니...
그리드 뷰같은 것은 좀더 피곤해질 수 있으나, 저장과 같은 기능들은 기존의 ASP.NET 방식보다 훨씬 빠르게 작성할 수 있답니다.
너무 길어졌으니... 다음에 못한 이야기를 해보겠습니다.
다음시간에 뵙겠습니다.
아 힘들다.
MVC패턴은 아주 오래전부터 사용하던 기법입니다.
Model View Controller...
대표적으로 MFC의 윈도어플 위저드가 MVC 패턴으로 생성해주고 있죠.
JAVA진영에서는 JSP 자체가 서블릿이기 때문에 서블릿 자체를 콘트롤러를 사용할 수 있어서 프래임워크없이 MVC로 웹어플리케이션 작성이 가능했습니다. 이렇게 작성하는 방법을 Model 2라고 부르지요. 어디서 생겨난 용어인지는 잘 모르겠습니다.
개념은 간단합니다. 요청을 받는 서블릿이 URI를 해석하여 Model 클래스의 메소드를 실행해 반환된 값을 View에서 보여준다... 헌데 요청하나에 서블릿이 하나가 기본이다 보니... 요청마다 서블릿이 있어야 --; 결국 유지보수에 문제점이..
그래서 매핑을 통해 하나의 콘트롤러에 몰아버릴 수도 있으나... 이경우
콘트롤러가 너무 복잡해지는게 문제지요. if문 많이 사용되겠지요.
스트럿츠라는 스타가 나오면서 자동화되어 많이 많이들 사용하게 되었지요.
최근에는 Spring MVC를 많이 사용하는 추세입니다.
MVC의 개념은 명확합니다.
1. 모든 비지니스 로직은 Model에서 다룬다.
2. View는 보여주기만 하자.
3. 콘트롤러는 이 둘을 연결하는 역할을 한다.
웹어플리케이션에 대한 이야기이니... Model은 대게의 경우 DB 핸들링이 되겠네요. 흔히 이야기하는 CRUD 4가지 액션이 되겠네요. 유효성 검사 역시 Model 에서 하는게 좋습니다.
이기능을 하는 클래스를 하나 만들어 두는 거지요. ADO/LINQ/DB 프래임워크... 무엇이든 관계 없습니다...
3.5이니 LINQ가 좋지 않을까 생각해보네요.
LINQ 자체를 쓰는것도 방법일테구요... 전통적으로 리파지터리 인터페이스와 클래스를 하나 더 만들어서 추후를 대비하는 기법을 많이 씁니다.
여튼, 모델은 끝났군요. 이 모델은 MVC 패턴 뿐만 아니라... ASP.NET 본래의 방법에서도 써먹기 좋겠지요.
아래처럼 써먹겠지요.
IBbsRepository bbsRepository = new BbsLinqRepository();
BbsArticle bbsArticle = new BbsArtcel();
bbsArticle.title = request["title"]
....
....
bbsRepository.add(bbsArtice);
bbsRepository.commit();
뭐 이런식으로 사용하면 되겠지요.
객체지향과 담쌓으신 분들을 위해 왜 라파지터리에 인터페이스가 필요할까도 한번 생각해 보면 좋을 것 같습니다.
말씀드렸다시피 ADO를 사용한 녀석이 될수도 있고 LINQ를 사용한 녀석이 될수도 있고 혹은 다른 프래임워크를 쓴 녀석이 될 수도 있으니... 인터페이스로 규약을 만들어 놓으면 바꿔치기가 쉽겠지요. 인터페이스는 바로 규약인 것입니다.^^;
위에서 작성한 코드는 MVC에서는 Controller에 들어가는 내용이 되는거지요.
모델이 완전히 분리가 된것 같네요.^^; - 사실 분리가 안됐습니다. new를 써버려서 강하게 결합되어 있지용.... 이 문제는 다음에 다시 이야기 해봐용, 이걸 해결하기 위한 기법이 바로 IoC/DI기법입니다-
IBbsRepository bbsRepository = new BbsLinqRepository();
bbsArticle = bbsRepository.getArticle(request["articleid"]);
게시글 상세 보기를 수행하는 콘트롤러의 한부분이 위와 같다고 하지요.
일단 bbsArticle이라는 엔티티 클래스에 내용이 들어가겠네요.
여기서 콘트롤러의 역할이 끝나면 안되지요. View로 전달을 해줘야겠지요.
return View("read",bbsArtice);
ASP.NET MVC는 위처럼 View로 보냅니다.
read.aspx 파일이 뷰가 되고, view에서 bbsArticle을 사용하도록 토스해주고 있네요.
read.aspx 파일에서 제목 : <%=Mode.title%> 이런식으로 사용하면 되는거지요.
MVC에서는 콘트롤러가 가장 중요한 녀석이지요. 중심에 서서 모델을 실행하고 결과를 다시 View에 전달하는 가장 핵심이 되는 녀석이죠.
ASP.NET MVC는 기본적으로 URL 라우팅이라는 기법을 통해 콘트롤러(하나의 클래스로 정의됩니다.)와 콘트롤러 클래스 내부의 메서드(액션메서드라고 합니다.)를 선택하게 됩니다.
기본적으로
/bbs/read/3
이런 요청이 들어오면 bbsController 클래스의 read 메서드를 실행하고 매개변수(id라고 설정했다고 가정)에 3을 넘기게 되지요.물론 위의 URL 패턴은 사용자 맘대로 변경 가능합니다.
RubyOnRails와 비슷한 면이 많습니다. 사실 비교 해보면... RoR의 영향을 엄청나게 받았다는 것을 알 수 있는 부분이 많지요. 이부분도 다음에 이야기해 보아요.
위 URL은 콘트롤러가 bbs 이며 메서드가 read 다. 그리고 매개변수는 3이다.
입니다. 콘트롤러가 bbs인데 bbsController의 인스턴스가 생성되는 이유는 규칙이기 때문입니다.
콘트롤러 명명 규칙이 xxxController인거지요. 이렇게 하자고 약속을 해버린 것입니다. path역시도 /Controller에 있죠.
View의 Path는 /View지요. 위 메소드의 기본 뷰는 /view/bbs/read.aspx 입니다. 이것 역시도 약속입니다. 강제하는 것이지요. 물론 바꿀 수도 있습니다만... 기본적으로 이렇게 하자고 권장을 하고 있습니다.
이런부분들이 RubyOnRails의 가장 큰 개념이기도 합니다. 설정보다는 규약이 프로그램하기 쉽다... 라는... 한마디로 응용보다는 암기가 더 쉽다...라는 거지요 ^^;
이제 명확히 분리가 됐네요.
MODEL은 아예 다른 DLL 파일로 만들어버렸으니 완전히 분리가 되어 있고...
CONTROLLER는 비지니스 로직 안들어가고 MODEL에서 정보만 가져와서 VIEW에 넘겨줬으니...
이제 남은건 VIEW가 보여주기만 하면 되겠네요.
헌데... 기존 ASP.NET 개발자분들이 헷깔리는 게 VIEW일꺼라 생각해 봅니다.
기존 ASPX와 전혀 다르다는 거지요. 기존 ASPX처럼 서버콘트롤을 사용하지도 못합니다.
그러다 보니 ASP.NET의 상징인 포스트백 사용도 안됩니다.
마술같은 ASP.NET Ajax 사용도 안됩니다... 뭐 이런 경우가? ㅋㅋ
MS는 ASP.NET을 왜 웹과 어울릴수 없는 포스트백 방식(이벤트드리븐)으로 만들었을까요?
생산성이죠. 예전 VB같은 방식으로 웹어플리케이션도 개발해 봐라~ 해서 나온거죠.
물론 그 방식이 상당히 웹과 안어울리는 방식같이 보이긴 하지만...요... 생산성 측면에서는 따라올 솔루션이 없죠.
ASPX 파일에 서버 콘트롤 올려다 놓고 load이벤트에서 DB 조회해서 바인딩 시키면 끝~~~;
코드도 워낙 짧아서 분리할 필요도 없고.. 페이지 하나 만드는데 1분이면 충분~~~; 생각대로 하면 됐죠.
2.0부터는 아예 코드가 필요없이 바인딩시킬수 있을 정도로 만들어 놨지요.
ASP.NET의 가장 큰 장점은 생산성인데... 그걸 버리고 왜 MVC로 가야 하느냐???
기존 ASP.NET 개발자들은 딜레마에 빠지게 됩니다.
그럼 왜 MVC를 써야할까요?
흔히 유지보수 이야기를 많이 합니다.
분리되어 있으니, 유지보수가 쉽고 명쾌하다는 거지요. 기존의 ASP.NET은 유지보수가 어렵냐?
사실 그렇지도 않습니다.^^; 개인적으로는 오히려 ASP.NET이 유지보수가 더 쉽지 않냐라는 생각입니다.
어짜피 대규모 프로젝트라는 건 말이죠... 작은 요소요소가 많아져서 대규모 프로젝트가 되는거지 하나의 요소가 엄청 커서 대규모프로젝트 혹은 엔터프라이즈급 이런 용어를 쓰는 건 아니거든요.
MVC가 웹어플리케이션에 상당히 잘 맞다는게 첫번째 이유같습니다.
요청->변경/조회->응답 이라는 웹어플리케이션 구조와 상당히 잘 맞는 다는거지요
콘트롤러->모델->뷰 그럴듯하죠?
그리고 N-tire기법이 활용될 수 밖에 없는 웹어플리케이션과 MVC 개념역시 잘 맞아떨어지고 있네요.
또한 MVC의 기본 원칙이 분리(의존성분리)이기 때문에 테스트주도개발이 가능하다는 거지요.
테스트 주도 개발에 대한 이슈는 다음시간에 이야기할께요. MVC를 쓰는 가장 큰 이유입니다.
그리고 한가지 더, 깔끔한 URL을 들수가 있겠네요. 검색엔진이 수집하기 쉽겠죠. 그리고 사용자에게도 친화적일테구요.
ASP.NET의 포스트백관련 기능이 안되는거지... 마스터 페이지, 인증, 국제화같은 기능은 여전히 지원되고 있구요.
예전부터 웹을 접하신 분들이라면 ASP.NET의 문제점을 서버콘트롤이라고생각할 것 같습니다.
자동화해놓은 것까지는 좋은데...
웹과 어울리기 힘든 이벤트 드리븐 방식을 채용했기 때문에 서버콘트롤이라는 개념을 도입한 거지요.
HTTP는 상태유지가 안되는 프로토콜이기 때문에.
버튼을 눌렀을 때 혹은 특정 이벤트를 발생시켰을 때 페이지 단위로 상태가 유지되어야 하는데요. 그래서ViewState라는 개념 만들게 되지요. 헌데 이게 좀 크다는 문제가 발생하게 되었지요.
서버콘트롤 디자인을 개발자가 하는 문제도 발생하게 되지요. 코더들이 알수가 없거든요^^; css 적용하기 좀 그런 구조지요. HTML이 실제 렌더링 되기 전까지 서버 콘트롤 코드만 보고는 이게 어찌 렌더링되려는지 알수 없다는거지요. 기존의 웹개발자들이 가장 어이없어하는 부분일것 같습니다. 또한 서버 콘트롤이 지원하지 않는 디자인 형태를 만들기 위해서는 어쩔 수 없이 스파게티코드가 생산될수 밖에 없구요.
ASP.NET은 생산성이 1차 목표였기 때문에 사실 개발자들이 모델부분만 따로 분리해서 개발하지 않죠. 코드비하인드기법을 활용하는 정도가 전부이지 않나 싶습니다. 그래서 모델/뷰가 너무나도 끈끈하게 한뭉탱이가 되어 있죠.
이말은 Nunit등과 같은 자동화 테스트 툴을 이용할 수 없다는 거지요.
대략 정리해 보자면....
빨리개발하고 싶다면, 데이타바인딩의 편리성을 사용하고 싶다면...
기존 ASP.NET을...
테스트주도 개발 방식, 확장성, 괜찮은 URL, 어라... 내가 개발자구나? 라고 느끼고 싶다면(?) MVC를 사용하면 될 것 같군요.
사실 MVC라는 것도 처음 개념만 잡히고 설정만 제대로 해놓으면... 쉽습니다. ASP.NET MVC는 비주얼 스튜디오가 유용한 템플릿을 많이 제공해주기 때문에 코드 노가다를 많이 줄일 수도 있습니다.
그리고 서버콘트롤에 거부감을 가지고 계시는 저같은 개발자분들에게는 MVC를 더 추천해드리고 싶네요.^^; 작은 프로젝트라 하더라도 말이죠.
MVC는 웹환경과 상당히 잘 맞다는 걸 다시한번 말씀드리고 싶군요.
다만 그리드를 통해 데이타바인딩이 주류인 프로젝트들은... 그냥 ASP.NET으로 금방 끝내버리시기 바랍니다. 그리드콘트롤하나 놓고 반인딩하면 끝나는데... 모델따로 만들고, 생소한 VIEW 메소드들 보면서... 고생할 필요는 없을 것 같네요.
보통 관리모드 만드는 것은 역시나... 제 생각에는 기존 방식이 훨씬 좋지 않나 싶습니다. 인트라넷도 마찮가지구요.
검색엔진 신경 쓸 필요도 없고, 사용자가 그닥 많지 않으니 사이즈 신경 쓸 필요도 없고...
신경쓸 게 없으니 말이죠. 하루면 될 일을 3일동안 할필요는 없겠지요.
끝내기 전에... 한말씀...
사용자는 MVC를 쓰든 기존 ASPX든, JAVA인지 PHP인지 전혀 신경 안쓴다는거죠.
개발자 입장에서는... 최대한 유지보수 편하게 만들어 놔야지요.
변경사항이 있을면 최소한의 수정만으로 바로 반영될 수 있도록 말이죠.
모델은 역시나 분리하는게 좋습니다. 아예 DLL을 따로 빼버리는게 가장 현명합니다.
물리적인 분리를 의미하니깐요.
그리고 인터페이스를 잘 활용하시면 좋습니다. 규약을 만들어 놓고 시작하는 거죠.
객체지향언어를 쓰면 인터페이스는 당연히 써줘야 예의지요.
인터페이스형으로 실제 클래스 인스턴스를 생성한다는 것 자체가... (인페이스의 변경이 없다면)
클래스를 사용하는 쪽의 코드 수정은 필요없다라는 걸 이야기하는 거니깐요.
실제 인스턴스화된 클래스 내용만 수정하면 되겠지요.
역시 A 클래스를 수정하지 않고 수정량이 많아서 B 클래스를 만들었다고 치죠.(인터페이스는 같은...)
그러면.. 이 클래스를 사용하는 클래스(콘트롤러)도 당연히 코드가 수정되어야 겠죠? 클래스명이 다를테니... IXxxx xxx = new xxx1(); -> IXxxx xxx = new xxx2(); 이런식으로요. 그래서 나오게 되죠. 스프링 프레임워크/ 윈저캐슬 같은 IoC 프래임워크가 말이죠.
Ioc는 new를 쓰지 않음으로써 최대한 결합을 느슨하게 해주는게 목표입니다.
Dependency Injection, 한국말로 의존성 주입..
구체적으로 스프링같은 프래임워크가 객체를 관리하며(자체는 싱글톤으로 동작), 필요한 객체에 인스턴스를 넣어준다는 거지요.
프래임워크가 어떤 객체를 관리하냐는 XML에 설정하는 방법을 쓰지요.
또 한가지... 말씀드릴부분이 있군요. 기존 ASP를 개발하셨던 분들의 가장 큰 고민은...
Request로 넘어온 값들을 어떻게 자동화할 수 없겠느냐 하는 것이었습니다.
게시글을 저장하는 시나리오를 생각해 보겠습니다.
title, writer, content, image 등의 폼이 있고, 같은 이름의 컬럼이 있다고 할때...
dim title, writer, content, image
title = request("title")
writer = request("writer")
content = request ("cotent")
image = request("image") '파일이겠지만 그냥.. 간단하게..
if (len(trim(title)) < 2) then
JsAlertAndHistroyBack("제목은 2자리 이상이어야 합니다.")
response.end()
end if
'.... 유효성 검사계속
insert bbs(title, writer,content,image) values(위의변수들...)
이런 방법을 사용했죠.
유효성 검사야... 뭐... 어쩔 수 없는 부분이라 치더라도...
request(xxx) 이걸 변수와 매핑하는 건... 노가다의 극치였죠.
방법이 없는 것은 아닙니다. 딕셔너리 객체를 만들어 request.form 객체를 넣어버리고 자동으로 sql 문을 만들 수 있는 함수를 만들어 줄 수 있습니다. 고급기법이군요.
여튼...
특정 변수에 요청에서 온 값을 자동으로 매핑할 수 있는 방법을 MVC에서는 자동으로 지원해주고 있습니다.
데이타 바인딩이라고 하지요.
액션메서드에 매개변수명을 폼변수명과 똑같이 선언하면 매개변수에 자동으로 할당됩니다.
혹은 매개변수에 엔티티클래스를 넣어주면 엔티티클래스의 프로퍼티명과 폼네임이 같을 경우 자동으로 프로퍼티에 넣어 주기도 합니다. 원하는 녀석만 선택적으로 필터링할 수도 있습니다.
이런 기술을 프래임워크가 지원해주니...
그리드 뷰같은 것은 좀더 피곤해질 수 있으나, 저장과 같은 기능들은 기존의 ASP.NET 방식보다 훨씬 빠르게 작성할 수 있답니다.
너무 길어졌으니... 다음에 못한 이야기를 해보겠습니다.
다음시간에 뵙겠습니다.
아 힘들다.
