2009-03-29 5 views

답변

5

지금 MVC에 대한 열정이 많습니다.하지만 새로운 개발 프로젝트를 시작하는 중이라면 아직 MVC 열차에 뛰어 들기 전에주의 깊게 고려해 보는 것이 좋습니다.

평범하지 않은 프로젝트의 대부분의 개발 팀에게는 심각한 고려 사항이 있습니다. 다음은 관련성이 가장 높은 것들입니다.

  • MVC는 개발자에게 더 많은 기술이 필요합니다. 그들은 HTML/CSS의 내부 작동뿐만 아니라 HTTP 작동 방식을 잘 이해할 필요가 있습니다. 클라이언트 측 코드의 경우 강력한 자바 스크립트 및 JQuery 기술이 필요하며 서버 측에서는 OO 주체의 고급 파악이 필요합니다. MVC를 최대한 활용하려면 단위 테스트 및 프레임 워크 조롱을 경험하십시오.

  • MVC 1.x 프레임 워크는 현재 Visual Studio의 RAD 기능에 많은 영향을 미치지 않습니다. 당신은 텍스트 편집기와 인텔리 센스를 얻습니다. 마법사가 없거나 드래그 앤 드롭 구성 요소가 없거나 속성 편집자가 없습니다.이 작업이 그렇게 나쁘지는 않지만 종종 사소한 UI를 작성하는 데 시간이 오래 걸립니다. 특히 경험이 부족한 개발자의 경우 더욱 그렇습니다.

  • MVC는 매우 새롭고 코드 샘플, 자습서 및 샘플 응용 프로그램은 매우 어렵고 범위가 제한되는 경향이 있습니다. 문서는 현재 약간 얇습니다.

  • 아마도 MVC 프레임 워크의 가장 큰 단점은 주변에 확립 된 성숙한 타사 시장이 없다는 것입니다. 웹 양식을 사용하면 시장에 수많은 고급 UI 제품군과 구성 요소가 있으며 차용 할 수있는 수많은 오픈 소스 프로젝트가 있습니다.

  • 많은 앱, 특히 비즈니스 앱의 경우 MVC 프레임 워크만으로 타사보고, 차트 및 고급 그리드 컨트롤이 부족한 경우 큰 문제가됩니다.

MVC는 환상적이며, 내가 사용할 수있는 위치에 있다면 매우 좋습니다. 그러나 웹 양식에 오래 동안 머무를 수있는 상당히 복잡한 프로젝트에는 실제 비용과 위험이 있습니다.

MVC의 다음 주요 버전이 특히 RAD 기능이 없기 때문에 많은 문제를 해결할 것으로 예상됩니다. 또한 MVC에 대한 열정은 플랫폼에 대한 제 3 자 지원을 많이 가져올 것으로 기대합니다. 그러나 모든 것이 잘 정립되기까지 시간이 걸릴 것입니다.

+0

좋은 점은 완벽한 보디가되고 싶지는 않지만, "ASP.NET MVC는 매우 새롭다 "- MVC 자체는 PARC에서 약 1979 년에 시작되었다. – Rob

1

나는 웹 사이트의 유형이 웹 사이트의 필요에 어느 것이 든 더 좋을지는 모르겠다.

많은 양의 코드없이 매우 빨리 처리 할 수있는 웹 사이트가 필요하고 HTML 마크 업에 신경 쓰지 않는다면 WebForms는 갈 길이 멀다.

컨트롤 괴물이라면 발생하는 모든 작업과 생성되는 마크 업을 제어 할 수 있습니다. MVC가 아마 당신을위한 것입니다.

MVC는 HTTP 모델의 추상화가 적어 의미가 적습니다. 그것은 WebForms의 ViewState와 같은 상태를 유지하지 않습니다.

0

나를위한 결정 과정은 매우 간단합니다. 모든 새로운 개발은 ASP.NET MVC로 수행됩니다. 사소한 수정이 필요한 기존 사이트는 계속해서 WebForms가됩니다. 주요 수정이 필요한 기존 사이트는 MVC로 이동할 수 있습니다.

내가 스위치를 만드는 기본적인 이유는 테스트 가능성과 디자인과 관련이 있습니다. IMO MVC 웹 사이트는 훨씬 더 테스트 가능합니다. 유닛 테스트로 뷰 로직을 테스트 할 수 있지만, HtmlHelper 확장을 사용하고 테스트하면 상당량의 뷰 로직을 테스트 할 수 있습니다. WebForms를 사용하여 코드 숨김을 테스트하기 위해 많은 노력을해야했기 때문에 수동 테스트를 위해 많은 앱이 남아있었습니다.

또한 아키텍처가 디자인 측면에서 볼 때 더 좋다고 생각합니다. 관심사가 명확하게 분리되어 있으므로 비즈니스 로직을 잘못된 위치 (예 :보기)에 삽입하는 것이 바람직하지 않습니다. 개념화 및 응용 프로그램 이해를 훨씬 쉽게 만듭니다. 또한 다른 레이어의 관계없는 비트가 없기 때문에 적은 노력으로 코드보기를 재사용 할 수 있습니다.

내가보기에는 현재 진짜 단점은 성숙하지 않았으며 이미 재사용 가능한 구성 요소가 많지 않다는 것입니다. 그래도 시간이 지남에 따라 변화 할 것으로 예상됩니다. 또한 MVC와 WebForms를 섞어도 가능하지만 다른 중요한 작업이 없으면 기존 앱을 가능한 대안으로 개조하는 것을 보지 못합니다. 다시 말하지만, 제 견해로는 MVC로 처음부터 시작해서 기존 앱을 사용해 보도록하겠습니다. 나는 그것이 응용 프로그램의 크기에 달려 있다고 생각하지만, 많은 중요한 페이지 수가있는 것은 많은 라우팅 예외를 가질 것입니다.

1

지난 4 주 동안 MVC에서 사용 가능한 자료를 읽고 다양한 비디오 및 자습서를 보냈습니다. 오늘 나는 실제 응용 프로그램에 대한 작업을 시작했습니다. 클라이언트는 잠시 결과를 기다리고 있습니다. 나는 이전의 대답들에 동의한다. (배워야 할 것이 많고, 많은 새로운 개념들, 제 3 자 구성 요소들 대신에 거의 없다.) 아직도 나는 mvc를 배울 시간을 보냈다 니 다행이다. - webforms로 숨겨진 html/css/jscript 행에 대한 두려움을 극복해야합니다. html 태그에 익숙해 지려면 시간이 필요합니다. 일단 당신이 할 수있는 가능성에 대해 알아낼 것입니다. 태그가 누락되지는 않을 것입니다. - 단위 테스트를 사용한 경험이 없다면 mvc가 단위 테스트와 함께 제공되는 가능성에 대한 훌륭한 소개를 제공한다고 생각합니다. - OO는 훨씬 더 많이 존재하며 mvc에서는 "명백합니다".
- 관심사 분리가 가능하고 자연 스럽습니다. aspx.cs 파일에서 gui와 비즈니스 논리를 혼용하지 마십시오.
- 더 이상 page_load가 없습니다 (그리고 n 개의 다른 단계). asp.net의 데이터 바인딩이 절대로 마음에 들지 않으면 mvc를 좋아할 것입니다. 나는 그것을 다시하지 않아도 기쁘다.

단점 : - 느립니다. 처음에는 매우 느립니다. webforms에서 거의 시간을 들이지 않는 것들은 mvc로 많은 시간이 걸릴 수 있습니다.
- 페이지가 더 이상 존재하지 않는 것도 큰 변화입니다. 그러나 일단 당신이 이것을 "내면화"하면 (시간 ...), 당신은 페이지를 놓치지 않을 것입니다. - O/R 매퍼도 필요합니다. 한 가지 더 배워야합니다. - 프레임 워크를 최대한 활용하는 데 관심이 있다면 많은 것을 익히고 익숙해 져야합니다. MVC 단위 테스트없이 절반 mvc입니다. 조롱 프레임 워크가없는 단위 테스트는 실제로 가능하지 않으므로 반드시 배워야합니다. 단위 테스트를 통해 절반을 달성했다고 생각할 때까지는 작업의 일부분을 자동화해야 할 필요가 있음을 알게되고, 또한 배워야합니다. 그것은 단지 끝이 없습니다 ....하지만 다시 한 번 이러한 기술을 사용하기 시작하면 어떻게 관리했는지 궁금해 할 것입니다.

관련 문제