출처 : 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 방식보다 훨씬 빠르게 작성할 수 있답니다.
너무 길어졌으니... 다음에 못한 이야기를 해보겠습니다.
다음시간에 뵙겠습니다.
아 힘들다.
출처 : http://www.talk-with-hani.com/archives/1216
2001년 2월에, 경량 프로세스(lightweight process)라고 막연히 불리며 떠오르던 경향에 대해 토론하기 위해여 앤디 헌트를 포함해 관심을 가진 사람들 17명이 스노버드에 모였습니다. 논의 끝에 이들은 이런 경량 프로세스의 움직임을 정리해 그 유명한 ‘애자일 선언문’을 발표합니다. 그리고 그 후 10년이 지났습니다.
10년이면 강산도 변한다는데, 애자일이 우리 개발자들에게 칼퇴근의 신화를 현실의 이야기로 만들어 줬나요? 아니면 책을 팔거나 세미나에서 강사로 돈을 벌기 위해서 그냥 새로운 이슈 정도로 만들어 놓은 마케팅이었을까요? 오늘의 글은 애자일 10년을 기념하는 의미에서 지극히 개인적인 경험을 바탕으로 한, 애자일에 대한 초간단 10주년 보고서입니다.
애자일 프랙티스의 서문에서도 밝혔듯이, 제가 애자일을 처음 접한 것은 약 8년 전쯤입니다. 당시 저는 선배 사원과 새로운 프로젝트에 투입되기 직전이었죠.
“선배! 기존 개발방법론보다 결과도 더 낫고 결정적으로 칼퇴근이 가능한 방법론이 있다는데, 이번 프로젝트에 적용해 보는 게 어떨까요?”
사실 선배가 칼퇴근이라는 감언이설(?)에 넘어오지는 않았지만, 그 당시 우리는 칼퇴근 이상의 근본적인 변화를 원했습니다. 프로젝트 일정으로 채워진 달력이 몇 번이나 바뀌었지만, 프로젝트의 내용은 변화가 없었기 때문입니다. 즉, 우리가 참여했던 프로젝트는 주인공과 배경만 바뀌고 스토리는 비슷한 드라마와 같았습니다. 프로젝트 제안서는 항상 고객이 원하는 것 이상을 보여주었지만, MS 프로젝트에 적힌 일정은 현실과 이상의 괴리를 처절히 깨닫게 해주었고, 제안서에 속은 고객은 허기를 달래려고 프로젝트 팀원들을 잡아먹으려 했으며, 목숨이 위태로워진 팀원들은 제안서에 그려진 이상향을 땅 위에 실현시키고자 프로젝트룸에서 청춘을 보내야 했습니다.
그리고 우리 앞에는 또 다른 프로젝트가 놓여 있었습니다.
당시에 XP를 적용하면서, 여러 가지 일을 겪었지만, 짝 프로그래밍을 하면서 부서의 부장님을 설득하는 게 무척 어려웠습니다. 즉, 짝 프로그래밍을 하는 모습을 보신 부장님이 ‘둘이 붙어 앉아서 노는 것’ 아니냐고 말씀하시면서, 개발이 제대로 될지 걱정하셨기 때문이죠. 아무튼 성과가 저희 대신 변명을 해주었기에, 부장님이 더 이상 짝 프로그래밍에 대해서 별 말씀하지 않으셨죠.
근본적인 변화를 꿈꾸면서 시작한 프로젝트는 절반의 성공을 거두었습니다(상당히 모호한 변명이지만… 정치적인 이유가 있었기 때문이죠). 절반의 성공이었지만, 저는 그 프로젝트를 통해 애자일의 묘미를 알게 되었습니다. 시간은 흘러, 애자일 실천방법을 적용한 프로젝트를 몇 번 더 했습니다. 10명이 조금 넘는 팀원들이 참여한 프로젝트에 애자일을 적용한 적도 있었고, 저 혼자서 북치고 장구치면서 애자일 프랙티스를 실천한 경우도 있었습니다.
요즘도 가끔 들어가는 개발자 커뮤니티 사이트에서, 흔히 말하는 SI성 프로젝트를 하는 개발자들이 일이 많거나 고객이 요구사항을 바꾸거나 동료 개발자나 관리자 사이의 관계 때문에, 프로젝트가 힘들다는 이야기를 많이 하시죠. 개발자들의 하소연 가운데 애자일 방법을 적용해서 해결할 수 없는 것도 많습니다. 하지만 애자일을 적용했을 때 해결할 수 있는 것도 있지만 현실이 그다지 개선되지 않는 것을 보면, 애자일 선언 이후 애자일이 우리의 현실을 개선하는 데 별로 기여하지 않았다는 생각이 듭니다. 이런 생각이 들자, 애자일 이거 정말 한때의 유행 아니었나 하는 의심도 듭니다.
나치의 선동가 괴벨스는 이런 말을 했죠. 거짓도 반복해서 들으면 진실이 된다고요. 저도 그런 경우가 있는데요. 실제로 경험해 보지 않았지만, 하도 많이 들어서 진짜로 그것을 경험한 것처럼 느낄 때가 있습니다. 즉 다른 사람의 시선으로 경험해 보지 못한 것을 인식하는 오류죠.
이런 오류는 어느 분야에나 있을 수 있습니다. 즉 새로운 개념이 소개되고 사람들이 열광하지만 실제로 그런 개념을 현실에 적용해서 결과를 내는 경우도 적죠. 기술이나 개념이 성숙하지 않아서 그럴 수도 있지만, 새로운 개념에만 매료되었을 뿐 현실에 그런 것들을 적용하고 자기 것으로 만드는 노력이 없을 때 그렇습니다. 새로움에 대한 열광이 식을 때, 사람들은 새로운 것도 실제로 적용해 보면 별 거 아니라는 생각을 하거나 다른 사람이 경험한 실패 사례에 초점을 맞춰서 예초부터 그런 개념은 현실에 맞지 않는다고 생각하기 시작합니다.
애자일이 탄생한지도 10년이 됐습니다. IT분야의 속도를 생각했을 때, 10년은 무척 긴 세월이죠. 애자일은 창조자들이 생각한 것만큼 더 나은 소프트웨어를 만드는 데 기여하고, 개발자들이 삶을 즐기도로 도와줬을까요? 아니면 한때의 말잔치였을까요? 그것도 아니면 무척 괜찮은 방법인데 사람들의 관심이 사라지고 애자일을 도입해서 실패를 경험하거나 경험하지 못한 분들의 폄하로 그 가치가 평가절하된 것일까요?
이런 물음에 답을 하려면 애자일이 생기게 된 근본 이유가 아직도 유효한지를 살펴봐야 합니다.
애자일을 현장에 적용하는 가장 큰 이유는 무엇일까요? 요구사항이라고 흔히 말하는 게 프로젝트 초반에 명확하지 않기 때문입니다. 즉 고약한 문제 합당한 해결에서 말하는 고약한 문제의 특성을 소프트웨어의 요구사항이 모두 담고 있기 때문입니다.
우리가 개발 현장에서 항상 하는 불만이 있습니다. 바로 고객이 요구사항을 바꿨다는 것이죠. 그런데 본질적으로 다른 의미를 이 문장으로 표현하는 경우가 있습니다.
우선은 최악의 케이스로 고객이 요구사항을 완전히 바꾼 경우입니다. 웹기반의 워드 프로세서를 만들고 있는데, 중간보고 자리에서 경영층이 웹 기반의 ERP를 만들라고 지시하는 경우죠. 이것은 정말로 고객이 요구사항을 손바닥 뒤집듯이 바꾼 경우로, 일정이나 예산 변경 없이 이런 요구사항을 반영하는 건 불가능하죠.
다른 경우는 상당히 현실적인 데요. 고객이 요구사항일 잘 모른 경우입니다. 다시 앞에서 예로 들은 웹 기반의 워드 프로세서를 만드는 걸 살펴보죠. 중간 보고 발표 때 마케팅 쪽에서 데모를 보고 나서, 멋진 마케팅 요소를 찾았는지, 기존에 없던 요구사항인 아래 한글 포맷으로 웹 문서를 변환하는 기능을 추가할 것을 요구합니다.
이런 요구사항 추가나 변경은 흔하죠. 그런데 개발자 입장에서는 왜 이런 요구사항을 개발 처음부터 이야기하지 않았는지 반문하면서, 마케팅 팀의 요구사항을 반영할지 말지를 두고 갑론을박을 버립니다.
앞에서 설명 드린 사례를, 우리는 모두 “고객이 요구사항을 바꿨어요.”란 말로 표현합니다. 하지만 둘은 요구사항의 변경 범위가 엄청나게 다르죠. 고객이 요구사항을 완전히 바꾼 것은, 프로젝트 팀에서 감담할 수 없는 겁니다. 하지만 고객이 요구사항을 잘 몰랐던 것은, 프로젝트 팀 내에서 감당할 수 있죠. 바로 애자일 방법을 사용해서 말입니다.
애자일 선언에 있는 것들에서 공통점을 발견할 수 있습니다. 개발의 과정에서 개발자들이 인간답게 살고 고객들과 좋은 관계를 통해서 비즈니스 기회를 창출하려는 인본적이고 자본주의 지향적인 노력도 있지만요. 제가 생각했을 때 가장 중요한 것은 변화를 포용려는 노력, 여러 가지 변화 중에서 요구사항이 변하는 것을 포용하려는 결과라고 생각합니다.
프로젝트 초반부터 고객이 모든 요구사항을 정하지 못하는 것을 프로젝트 팀에서 포용하기 위해서, 절차와 도구보다는 개인과 그들 사이의 상호작용에, 과도한 문서보다는 돌아가는 소프트웨어에, 계약보다는 고객과의 상호작용에, 계획을 추종하기보다 변화에 대응하는 것에 주안점을 두는 것이죠. 그렇다 보니 이런 현상들을 변화를 포용하여 기민하게 대처하는 것을 담아내려고,애자일(Agile)이라는 사상과 움직임이 탄생한 것이죠.
그런데 이런 사상을 실천하거나 고민하지 않으면, 애자일을 마치 변화무쌍한 고객의 요구사항에 대응할 수 있는 은총알이라고 생각하죠. 하지만 앞에서 말씀드렸듯이, 애자일이 포용할 수 있는 요구사항이 바뀌었다는 것은, 고객이 요구사항을 잘 몰랐던 경우입니다. 즉 고객이 요구사항을 제로 베이스에서 만들었다면, 원점부터 모든 것을 봐야 하죠.
아울러 애자일이라는 말 때문에, 애자일을 마치 아무렇게나 해도 되는 방법이나 설계 단위는 치워버리고 구현에만 급급한 해결책이라고 생각하는 경우도 있습니다. 이것도 넌센스죠. 애자일의 구체적인 실천방법을 본다면, 구현만 하는 게 아니라는 걸 알 수 있습니다.
애자일을 실천하려면 구성원들의 역량이 높아야 합니다. 역량이라는 것이 단순히 기술적인 것만을 뜻하는 게 아닙니다. 프로젝트 내에서 모든 것이 변할 수 있기 때문에 변화에 대해서 항상 열려 있어야 하고, 동료와 결과를 낼 수 있게 신뢰 기반으로 관계를 형성해야 하고, 새로운 것을 배우려는 자세가 되어야 하죠.
모든 소프트웨어 개발에서 설계가 중요하듯이 애자일에서도 설계를 반드시 해야 합니다. 하지만 그 수준이 고객의 요구사항을 구현하는 데 도움이 되는 수준이어야 합니다. 아키텍트가 아키텍처의 완결성을 위해 설계문서에 과도하게 집착하는 것은, 변화하는 요구사항에 대응하는 적절한 방법이 아닙니다. 설계문서의 완결성보다는 팀원들이 아키텍처를 이해하는 수준에서 멈추고 변화하는 요구사항을 관리하도록 역량을 쏟는 게 더 낫습니다.
길게 말씀드렸지만 애자일이 탄생한 근본원인이 요구사항이 모호하다는 것은 아직도 해결되지 않은 문제입니다. 그렇기에 애자일이 아직도 유효한 방법이라고 생각합니다. 다만 애자일의 어원 자체가 변화를 포용하는 기민함을 뜻하는 데서 출발했지만, “애자일 한다면서, 그렇다면 요구사항을 막 바꿔도 되는 거 아니야?” 처럼 애자일이라는 말이 주는 묘한 뉘앙스를 악용하는 사례나, 직접 경험해 보지 못하고 다른 사람의 경험으로 애자일을 판단하기 때문에 그 효용성에 대해서 좋게 판단하지 않는 것 같습니다.
물론 애자일을 성공적으로 적용해서 사용하시는 사례도 실패 사례만큼 많을 겁니다. 제가 경험한 개발현장이나 인터넷을 통해서 접하는 우리네 개발자 이야기를 들어보면, 애자일을 통해서 충분히 개선할 수 있을 것이라는 생각이 들 때가 많습니다. 그래서 애자일 10주년을 기념하면서 조금 긴 글을 써 봅니다. 오늘 글은 애자일 프랙티스를 번역하면서 쓴 서문의 마지막 문장을 인용하면서 마무리하겠습니다. 더 나은 내일을 위해서! 노력해야겠습니다.
우리네 프로젝트 인생이 행복해지기 위해서, ‘내가 바꿀 수 없는 것’도 결국 바꾸어야 합니다. 그러나 우리에게 두 가지 길이 있습니다. 즉, ‘내가 바꿀 수 있는 것’에 열정을 쏟으며 조금 더 나은 오늘을 만드는 것과 ‘내가 바꿀 수 없는 것’을 탓하며 ‘내가 바꿀 수 없는 것’이기에 누군가의 도움만을 바라며 똑같은 오늘을 보내는 것입니다.
어느 쪽을 선택할지는 개인의 문제입니다. 다만 여러분이 조금씩 개선되는 길을 선택하였다면 애자일에서 도움을 많이 받으실 겁니다!
