MVC보다 ASP.NET WebForms를 선호하는시기

Microsoft가 말한 것을 알고 있습니다

ASP.NET MVC는 WebForms를 대체하지 않습니다.

그리고 일부 개발자들은 WebForms가 MVC보다 개발 속도가 더 빠르다고 말합니다. 그러나 코딩 속도는 기술과 함께 편안함 수준으로 떨어 지므로 그 정답에 대한 답변을 원하지 않습니다.

ASP.NET MVC가 개발자에게 응용 프로그램을보다 강력하게 제어 할 수 있다는 점에서 WebForms가 더 이상 사용되지 않는 이유는 무엇입니까? 또는 새로운 개발을 위해 언제 MVC보다 WebForms를 선호해야합니까?

Webforms vs. MVC는 현재 뜨거운 주제로 보입니다. 내가 아는 모든 사람은 MVC가 다음 위대한 일이라고 선전합니다. 그것에 약간의 dabblings에서, 그것은 괜찮아 보이지만, 나는 그것이 webforms의 끝이라고 생각하지 않습니다.

내 추론과 MVC를 통해 웹 양식을 선택하는 이유에 대한 추론은 하나가 다른 것보다 나은 것이 아니라 비즈니스 관점과 관련이 있습니다.

시간 / 돈은 웹 양식이 MVC보다 선택되는 가장 큰 이유입니다.

대부분의 팀에서 웹 양식을 알고 있고 MVC를 빠르게 익힐 시간이 없다면 생성되는 코드의 품질이 좋지 않을 수 있습니다. MVC의 기본 사항을 익힌 다음 복잡한 페이지로 들어가서 수행해야하는 작업은 매우 다릅니다. 학습 곡선이 높기 때문에이를 예산에 반영해야합니다.

웹 양식으로 작성된 대규모 웹 사이트가있는 경우 사이트에 서로 다른 유형의 페이지가 두 개가 없도록 웹 양식으로 새 페이지를 만드는 경향이 더 큽니다.

나는 이것이 전혀 또는 전혀 접근하지 않는다고 말하지는 않지만, 특히 팀의 모든 사람들이 MVC에 익숙하지 않은 경우 두 가지가 모두 있으면 코드를 유지하기가 어려워집니다.

우리 회사는 최근 MVC로 3 개의 테스트 페이지를 수행했습니다. 우리는 앉아서 그들을 설계했습니다. 우리가 겪은 한 가지 문제는 대부분의 화면에 동일한 페이지에보기 및 편집 기능이 있다는 것입니다. 결국 페이지에 둘 이상의 양식이 필요합니다. 우리가 마스터 페이지를 사용하지 않는 한 큰 문제는 없습니다. 우리는 webforms 페이지와 MVC 페이지가 동일한 모양과 느낌을 위해 동일한 마스터 페이지를 사용할 수 있도록 개정해야했습니다. 이제 추가 중첩 계층이 있습니다.

이러한 페이지가 올바른 MVC 분리를 따르도록 완전히 새로운 폴더 구조를 만들어야했습니다.

나는 3 페이지에 대한 파일이 너무 많다고 생각했지만 그것은 내 개인적인 의견입니다.

내 의견으로는 MVC를 사용하기 위해 사이트를 업데이트하는 데 시간 / 돈이 없다면 MVC보다 webforms를 선택하는 것입니다. 이것에 반쯤 반박했다면, 지금 가지고있는 웹폼보다 나을 것입니다. 더 나쁜 것은 경영진이 알고있는 것보다 열등한 것으로 볼 수 있기 때문에 엉망인 경우 회사에서이 기술을 실패로 설정할 수도 있습니다.

3 년 동안 ASP .Net WebForms 응용 프로그램을 개발했으며 하루 동안 MVC 자습서를 수행 한 후 판매되었습니다. MVC는 거의 항상 더 나은 솔루션입니다. 왜?

• 페이지 라이프 사이클이 더 간단하고 효율적입니다.
• html 컨트롤 외에 컨트롤과 같은 것은 없습니다. ASP .Net이 생성하는 내용을보기 위해 출력을 디버깅 할 필요는 없습니다.
• ViewModel은 강력한 성능을 제공하고 수동 제어 바인딩을 수행 할 필요가 없으며 바인딩과 관련된 많은 오류를 제거합니다.
• 한 페이지에 여러 양식을 가질 수 있습니다. 이것은 WebForms의 심각한 제한이었습니다.
• 웹은 상태 비 저장이며 MVC는 웹 아키텍처와 더 밀접하게 일치합니다. Webforms는 ViewState를 도입하여 상태와 버그를 소개합니다. ViewState는 자동으로 백그라운드에서 작동하므로 항상 원하는 방식으로 동작하지는 않습니다.
• 요즘 웹 애플리케이션은 ajax와 함께 작동해야한다. 더 이상 전체 페이지를로드 할 수 없습니다. MVC는 JQuery를 사용하여 아약스를 훨씬 더 쉽고, 쉽고 효율적으로 만듭니다.
• 페이지에 여러 양식을 가질 수 있고 아키텍처는 URL 호출에 의해 구동되므로 JQuery를 사용하여 편집 양식과 같은 다른 양식을 현재 페이지에로드하는 것과 같은 펑키 한 작업을 수행 할 수 있습니다. 이것이 무엇을 할 수 있는지 알게되면 놀라운 일을 쉽게 할 수 있습니다.
• ASP .Net WebForms는 html에 대한 추상화 일뿐만 아니라 매우 복잡한 것입니다. 때로는 이상한 버그가 발생하여 필요 이상으로 오랫동안 문제를 겪을 수 있습니다. 많은 경우에 실제로 무엇이 잘못되고 있는지 알 수 있지만 그것에 대해 아무것도 할 수 없습니다. 당신은 이상한 해결 방법을 마칩니다.
• WebForms는 디자이너에게 좋은 기술을 제공하지 않습니다. 디자이너는 종종 html로 직접 작업하는 것을 좋아합니다. MVC에서는보기이며 WebForms에서는 반나절의 작업입니다.
• 웹 플랫폼이 빠르게 발전함에 따라 WebForms는 계속 유지되지 않습니다. HTML5의 새로운 태그 나 기능을 인식하지 못하지만 비싼 타사 컨트롤을 얻거나 Microsoft가 업데이트를 발행 할 때까지 기다리지 않는 한 여전히 동일한 내용을 렌더링합니다.
• WebForms의 컨트롤은 많은 방법으로 제한합니다. MVC에서는 JQuery 라이브러리를 가져 와서 템플릿에 통합하면됩니다.

WebForms가 발전함에 따라 위의 문제 중 일부가 어느 정도 해결되었다는 것을 알고 있지만 이것이 원래의 경험이었습니다. 프로젝트가 이미 사용하지 않는 한 WebForms에 대한 비즈니스 사례를 찾는 것이 매우 어렵다는 것을 알 수 있습니다.

Microsoft 의 MVC 전문가 인 Scott Guthrie 에게 이메일을 보냈습니다 . 그리고 아마도이 질문에 대답 할 수있는 가장 유능한 사람입니다. 그는 대답하기에 충분히 친절했습니다.

"다른 고객들은 다른 프로그래밍 방식을 찾고 있으며 WebForms를 좋아하고 훌륭하다고 생각합니다. 다른 사람들은 MVC를 좋아하고 훌륭하다고 생각합니다. 그래서 우리는 두 가지 모두에 투자하고 있습니다."

나에게 이것은 기술적 인 문제가 아니라고 말합니다. 당신이 원한다면 그것은 "소프트 이슈"에 가깝습니다. 개인적인 취향 중 하나. 이것은 당신 중 몇몇이 말한 것과 일치합니다.

모든 답변에 감사드립니다.

이것은 많은 답변이있는 오래된 질문이지만 아무도 목록에있을 것으로 예상되는 답변이 없었습니다.

짧은 대답은 다음과 같습니다.

• 최신 프로그래밍 규칙과 업계에서 채택 된 ASP.NET 플랫폼 패턴을 사용하여 웹 응용 프로그램을 올바르게 작성하려면 ASP.NET MVC를 사용하십시오. 단점은 HTML과 클라이언트 측 리소스 (자바 스크립트, CSS)가 작동하는 방식을 알고 학습 곡선이 가파르지만 일단 파악되면 갑자기 끝나는 MVC 프로그래밍 사고 방식을 강화하는 것입니다.
• GUI 중심의 RAD (Rapid Application Development) , 드래그 앤 드롭 방식을 사용하여 무언가를 매우 빠르게 프로토 타이핑 하기 위해 ASP.NET Web Forms를 사용하십시오. 15 분이며 솔루션은 개발자가 지원하는 것이 아닙니다. 또는 GUI 또는 Windows Forms 개발 에 대한 배경 지식이 있고 지식을 웹으로 이전하려는 경우 ASP.NET Web Forms를 사용하십시오 .

그러나 이것을 올바르게 보려면 각각의 역사를 이해해야합니다.

ASP.NET Web Forms는 Visual Basic 6 ActiveX 컨트롤, 서버의 VB6 DLL 및 ASP Classic을 사용하여 동적 웹 응용 프로그램을 구축 한 사람들에게 Microsoft의 대답이었습니다. 당시에는 이러한 Microsoft 도구를 사용한 웹 개발이 엉망이었습니다. ASP.NET Web Forms는 당시 Windows 스택에서 생산적인 비즈니스 프로그래밍을 수행하는 방법에 대한 드로잉 보드로 돌아가는 Microsoft의 결과물 인 .NET Framework 전체와 함께 놀랍고 아름답습니다.

전체 접근 방식은 개발자에게 Windows 응용 프로그램 개발과 매우 유사하지만 인터넷 서비스의 힘을 사용하여 두 가지 이점을 모두 제공하는 것이 었습니다. 아이디어는 VB6 / WinForms "양식"(창)과 마찬가지로 웹 페이지 도 양식 (창과 마찬가지로 양식) 이며 그 양식에서는 레이블, 텍스트 상자, VB / WinForms GUI 개발자에게 익숙한 데이터 그리드, 버튼 및 기타 사항.

버튼으로 무언가를 수행하려면, 드래그 앤 드롭 한 후 디자이너에서 버튼을 두 번 클릭하고 코드 편집기에서 붐을 일으켜 "클릭"이벤트가 발생할 때 수행 할 작업을 양식에 알려줍니다. 이것이 바로 Windows GUI 개발자 가 VB6의 GUI 툴링과 경쟁 툴을 사용하여 소프트웨어를 생성 한 방식입니다 . 단, 이제 코드가 서버에서 실행되고 있습니다! 와!

이것은 2002 년 기술이었습니다. RAD 개발을 위한 인터넷 지원 GUI 솔루션에 대한 해답으로서 놀랍고 아름다웠으며 , 비즈니스 목표를 달성해야하는 지저분한 소프트웨어 개발자의 세계에 힘을 실어주었습니다.

불행하게도,이 프로그래밍 모델은 Windows GUI 프로그래밍의 은유를 강조하여 필요한 구현 세부 사항, 이벤트 수명주기를 수용하는 데 필요한 모든 방해 수하물 및 간단한 HTML의 미묘한 세부 사항을 제거합니다. 이러한 드래그 앤 드롭 구성 요소 및 컨트롤이 출력하는 스크립트. 그리고 마지막 날, 실제 응용 프로그램을 지원하는 개발자는 필연적으로 이러한 구성 요소에 대해 깊이 파고 들어가거나 직접 작성해야했으며 결과적으로이 인프라와의 전투, 말뚝 박기 더미에 쌓인 전투, 머리를 당기고 눈물.

백업 손을 씻으십시오. 비즈니스 문제를 다시 살펴 보겠습니다. 우리의 사업 목표는 무엇입니까?

우리는 웹 애플리케이션 을 구축하고 관리해야 합니다 . 우리의 제약은 HTTP, HTML, Javascript 및 CSS에있는 월드 와이드 웹을 가지고 있고 서버에는 비즈니스 규칙, 데이터베이스 및 소수의 훌륭한 프로그래밍 언어 (예 : C #)가 있다는 것입니다. 개발 방법론을 추진하려면이 Windows GUI 메타포가 실제로 필요합니까? 왜 우리는 응용 프로그램 문제에만 집중할 수없고 GUI 비유를 피할 수 없습니까?

ASP.NET MVC가 등장한 곳입니다. "Alt.Net"이라고 불리는 개발자들이 적절하고 순수한 소프트웨어 개발 원칙으로 돌아 가고자하는 반란이 시작되었습니다. 더 이상 번거롭지 않고 비즈니스 목표와 소프트웨어 모범 사례에만 집중하십시오.

이 경우에 이것이 실제로 의미하는 것은 :

1. 우려의 분리 . 예를 들어, 데이터 컴포넌트는 데이터 렌더링 방법을 알 필요가 없으며 데이터베이스 연결 구성 세부 사항으로 마크 업을 볼 필요가 없으며, 이러한 방식으로 개발자는 편집 및 편집시 관심 영역에 집중할 수 있습니다. 테스트 코드.
2. HTML 및 관련 리소스의 완벽한 노출에 대한 노출 및 완벽한 지원 . Web Forms에서는 HTML이 사용되지 않으며 개발자는 그에 대한 소란을 피해야합니다. ASP.NET MVC에서는 개발자가 이러한 세부 정보를 관리하는 것이 좋습니다 . 사실 그것은 필수입니다. 여기서 장점은 개발자가 HTML, CSS 및 스크립트의 깔끔한 의미를 인식하고 반대하지 않고 함께 작업 할 수 있다는 사실을 다시 배울 수 있다는 것입니다.
3. 비즈니스 객체의 테스트 가능성 . 컨트롤러와 모델은 프로그래밍 방식의 단위 테스트에 훨씬 적합하므로 비즈니스 목표를 달성하기 위해 구현을 검증 할 수 있으며 변경 사항이 중단되지 않는지 확인할 수 있습니다. Web Forms를 사용하면 구성 요소가 개별적으로 테스트되도록 설계되지 않았고 전체 개발 결과가 페이지 양식 과 이벤트 수명주기를 중심으로 비즈니스 로직과 프리젠 테이션 로직이 서로 밀접하게 연관 되어 있으므로 테스트하기가 어려웠습니다 .

Javascript는 고급 프로그래밍 언어와 마찬가지로 HTML은 이미 매우 높은 수준의 마크 업 언어입니다. 우리가 어셈블리 언어와 C를 다루고 있다면 전체 이야기는 달라졌을 것입니다.

2 위로 확장 한 ASP.NET MVC의 또 다른 목표는 개발자가 솔루션의 '보기'부분에 대한 프런트 엔드 세부 정보를 구성하고 나머지 업계가 구축 한 풍부한 기반을 활용할 수 있도록하는 것입니다. 프론트 엔드 클라이언트 플랫폼

ASP.NET MVC 개발자는 서버 측 아키텍처와 싸우지 않고 풍부한 Javascript 라이브러리와 클라이언트 측 템플릿 기술을 사용하여 집에서 느낄 수 있습니다. 웹 양식 당신이 경우를 제외하고는, 전혀 HTML 또는 스크립트를보고 싶어하지 않기 때문에 이것은 원래 ASP.NET 웹 폼의 경우 아니었다 정말로 가지고 있으며,이 경우에, 조심, 그것은 약한 아니다 마음의.

ASP.NET MVC로 완전히 변환하고 완전히 돌아 왔으며 되돌아 보지 않았습니다. 여전히 매우 큰 WebForms 앱을 여러 개 유지해야한다고 말했습니다. 여기에 내가 가져 가라.

WebForms
그리드와 관련하여 심각한 무거운 리프팅이있을 때 사용하십시오. 표 형식에 잘 맞는 간단한 데이터 집합이 있고 사용자가 레코드를 업데이트 할 수있는 간단한 방법을 제공하고자 할 때 그리드 컨트롤은 정말 좋습니다. 예, MVC 4에는 정말 멋진 Ajax 목록 유형의 항목이있어서 잘 작동하지만 비즈니스에서 어제 무언가를 실행해야하며 좋은 구식 그리드가 훌륭하게 작동하고 사용자는 행복합니다. 기쁨으로 그리드를 가로 질러 탭할 수 있습니다. 저에게는 이것이 WebForms에있어서 가장 좋은 것입니다. 하지만 Ryan은지적한 코드 숨김 파일에서 펜스의 양면을 재생하기 때문에 WebForms가 큰 혼란을 초래할 수 있습니다. 그것은 모든 컨트롤러 유형의 물건을 당신의 시야와 혼합 유지하기 위해 장미와 가시가 될 수 있습니다.

MVC
실제로 롤업하고 싶을 때 응용 프로그램을 처음부터 시작할 수있는 경우에 사용하십시오. 명확하게 정의 된 MVC 응용 프로그램을 사용하는 것은 시작하기에 조금 더 많은 작업이지만 유지 관리 성의 이점은 초기 설치 비용을 능가합니다. 흥미로운 Ajax 상호 작용을 원한다면 깨끗한 URL 및 경로와 같은 코드로 모델을 작성하고 앱의 전체 흐름을 제어 할 수 있어야합니다. 이것은 분명히 갈 길입니다. 처음에는 익숙해 지지만 그린 필드 앱에는 더 나은 옵션이라고 생각합니다.

결론적으로, 그것은 그리드와! grid로 귀결됩니다. :)

내 경험:

• 1 년 동안 CakePHP 프로젝트를 작성했습니다.
• 6 개월 동안 중간 규모의 Webforms 프로젝트를 완료했습니다.
• 3 년 동안 Windows Forms 프로젝트에서 근무했습니다.

그 경험 후, 나는 webforms를 사용하여 다른 응용 프로그램을 작성하려고 시도했지만 webforms가 html, javascript 및 css를 사용하는 응용 프로그램을 개발하고 있다는 사실로부터 webforms가 개발자를 보호하려고 시도하는 방법에 대해 하루 동안 어려움을 겪고 좌절했습니다.

그런 다음 MVC를 사용해 보았고 출력을 더 직접 제어하고 CakePHP의 MVC 패러다임에 대한 경험을 통해 하루 약 1/2에 원하는 방식으로 간단한 앱을 완성 할 수있었습니다.

jQuery와 같은 강력한 UI 프레임 워크를 사용하면 대량의 사전 빌드 된 UI 구성 요소를 사용하여 출력을 직접 제어하지 않아도됩니다.

내 배경은 Windows 개발이기 때문에 webforms를 선호합니다.

developmnt의 속도는 중요한 문제이며, 인도의 누군가에게 문제를 쉽게 전달하여 양식으로 밤새 고칠 수 있습니다. 또한 페이지에 속도 문제가 있으면 asp.net 속도에 대한 정말 좋은 책이 편리합니다 (Rick Kiessig는 사람입니다).

webforms는 전 Windows 사람들을위한 것입니다 mvc는 웹 사람들을위한 것입니다

그러나 현대 세계에서 Rick은 멋진 책을 썼습니다. 인도에서 서버는 매일 속도가 빨라지고 저렴한 코더가 있습니다.

내 2 센트는 옵션이있는 경우 항상 새 프로젝트에 ASP.NET MVC를 사용하는 것입니다. 내 생각에, webforms는 웹 앱을 개발하는 좋은 방법이 아닙니다.

기본 REST를 추상화하는 것은 좋지 않다고 생각합니다. 전체 포스트 백 모델이 나쁘고 GUI 편집기에 의존하여 html / css를 전달하는 방식이 나쁩니다. 마법사 및 GUI와 같은 항목에 대한 강조가 잘못되었습니다 .URL 나쁘다.

나는 모든 답변을 읽었으며 개인적인 경험이 위의 답변에 무언가를 추가 할 것이라고 생각합니다.

3-4 년 전에 Webforms를 사용하여 2-3 개의 웹 사이트 프로젝트를 개발했습니다. 그 당시 MVC는 주변에 없었거나 들어 보지 못했습니다. 세부 사항에서 HTML을 배울 필요가없고 웹 컨트롤이 많이 도움이 되었기 때문에 자연스럽게 (사전 웹 개발 경험이없는 Win-forms 개발에서 나왔습니다) 빠릅니다. .

이제는 결국, 최근까지 웹 프로젝트를 수행하지 않았으며 WPF를 사용하여 일부 Windows 응용 프로그램을 작성했습니다.

며칠 전 나는 웹 사이트에 대한 아이디어를 가지고 그것을 개발할 생각을했습니다. 이번 MVC 주변에서는 (어느 곳에서나 이야기해야했기 때문에 MVC를 선택했기 때문에) 내가 여전히 배우고 함께 구축하고 있기 때문에 프로젝트는 여전히 개발 단계에 있습니다.

그래서, 내가 찾은 주요 차이점은 다음과 같습니다.

• Windows 개발에서 오는 사람에게는 웹 양식이 항상 유리합니다. Windows 개발자를위한 Asp.net 학습 곡선이 약간 가파 릅니다.

• 다른 기술의 웹 개발에서 오는 사람에게는 MVC가 최신 기술을 모두 모방하기 때문에 선호됩니다.

• HTML 및 CSS에 대한 지식이 풍부하면 MVC에서 개발이 더 쉽고 깨끗해집니다.

• 배포는 여전히 문제입니다. 웹 양식에서는 복사하여 붙여 넣기 만하면됩니다. 그러나이를 위해서는 몇 가지 작업을 수행해야합니다.

요컨대, 둘 다 여기 잠시 동안 머물 것입니다.

이 스레드에 대한 기존 15 가지 답변 중 아직이 고려 사항을 제시하지는 않았지만 고려할 가치가 있다고 생각합니다.

내 경험상 Web Forms는 MVC보다 Win Forms 및 WPF와 더 유사합니다. 이를 감안할 때 팀이 해당 기술에 대해 가장 많은 경험을 가지고 있거나 Web Forms 프로젝트가 기존 (또는 동시에 개발 된) Win Forms와 동일한 데이터 세트에 인터페이스를 제공 할 때 WPF 프로젝트. 그렇게하면 응용 프로그램 논리가 둘 사이에서 매우 유사 할 수 있으므로 개발자가 프로젝트간에보다 쉽게 ​​교차 할 수 있습니다.

다른 답변에서 지적했듯이 MVC 프레임 워크의 개발은 Microsoft에 비해 Ruby, PHP, Python 등의 웹 개발과 유사합니다. 따라서 자연스럽게 MVC의 선택은 다른 답변에 제출 된 요소와 함께 해당 영역의 팀 경험에 영향을받을 수 있습니다.

몇 년 전 MVC에 가지 않은 이유는 Microsoft의 미성숙 한 기술이기 때문입니다. 지난 몇 년 동안 우리는 이제 더 성숙한 버전 (4)을 사용하고 있으며 MS는이 작업을 수행 할 위치에서 문제를 해결 한 것으로 보입니다. 그러나 버전 4에서 사용하려는 기능에 Windows 2012 서버 (IIS8을 통한 웹 소켓)가 필요하므로 MVC를 사용하여 주요 LOB 앱을 개발하는 데 여전히 주저하고 있습니다. 1 년 후에는 더 많은 타사 제어 기능을 사용할 수 있고 기술이 정착했으며이를 지원할 인프라를 갖추게되면서 MVC를 더 많이 받아 들일 것입니다.

이 결정은 선호도, 요구 사항 또는 지식과 경험에 따라 다릅니다.

MVC 학습 교육 또는 배달 시간. 이 모든 것은 하나 또는 다른 aproach를 선택하는 것이 중요합니다.

하나가 다른 것보다 낫지 않습니까, 단순히 aproach 또는 framework 모두 장단점이 있습니다.

성격 MVC 3을 선호합니다. 나만의 경험을 시도해 보는 것이 좋지만 MVC의 프로그램은 깨끗하고 재미 있고 유연하며 확장 가능하며 안전하고 체계적인 방법이라고 말할 필요가 있습니다.

문안 인사,

MVC 대신 WebForms를 선택하는 유일한 이유는 MVC보다 WebForms에 대한 타사 UI 컨트롤이 훨씬 많기 때문입니다. WebForms로 너무 많이 일했기 때문에 MVC를 선택하고 신선하고 새로운 것이지만 여전히 MS 상점에서 일하고 싶습니다. :)

기본적으로 WebForms에서 viewstate를 끄고 모델 바인딩 및 서버 측 컨트롤 대신 ViewModels 및 if / for 루프를 사용하는 것을 막을 수있는 것은 없습니다.

이 WebForms 또는 MVC 코드입니까?

<% foreach (var item in Model.Items) { %>
<p><%: item.Name %></p>
<% } %>

WebForms에서 찾은 유일한 제한 사항은 Dependency Injection / Inversion of Control을 사용하는 경우 WebForms 페이지에 매개 변수가없는 생성자가 있어야하므로 생성자를 삽입 할 수 없으므로 속성 삽입을 사용해야한다는 것입니다. 이것이 정말로 큰 문제입니까?

ASP.NET MVC는 실제로 Ruby에 대한 해답이며 가능한 최신 서버에서 브라우저 (클라이언트)를 분리하는 새롭고 트렌디하며 (IMO) 더 나은 방법입니다.

ASP.NET Webforms 는 거의 모든 것에 직접 액세스하여 서버 쪽에서 클라이언트를 제어 할 수있게 해줍니다. 본질적으로 뷰와 컨트롤러는 동일하며 많은 전력을 공급하며 대부분 혼란스러워합니다.

ASP.NET MVC 는 웹 양식으로 제공되는 .aspx 파일과 .aspx.cs 파일의 긴밀한 결합을 분리하여 뷰와 컨트롤러를 분리합니다.

본질적으로 차이점은 뷰 파일에 데이터 를 표시 하기 위해 훨씬 더 많은 처리 (일반적으로 모든 처리)를 수행 하고 비즈니스 논리와 나머지를 컨트롤러에 남겨 두어 규칙에 따라 데이터를 깔끔하게 유지하지만 각각에 대한 액세스를 줄입니다. webforms 이외는 허용합니다.

제 생각에는 그것들은 충분히 관련이 있으며 선호도와 관련하여 거의 동일한 기능을 가지고 있습니다.

훌륭한 WebForms 개발자는 훌륭한 MVC 개발자와 마찬가지로 강력한 제품을 생산할 수 있습니다. 그러나 MVC를 채택하도록 강요하려는 위대한 WebForms 개발자는 부족할 것입니다. WebForms를 제공하는 훌륭한 MVC 개발자도 마찬가지입니다.

이들은 완전히 분리 된 실체가 아니며, Microsoft가 둘 다 계속 지원하는 한, 각기 뛰어난 개발자 그룹을 계속 보게 될 것입니다.

우리가 우리가 사용하는 기술에 능숙하다고 가정하면 이것은 개인적인 선택에 관한 것입니다. 나는 WebForms 디자인 접근 방식을 수년 동안 사용해 왔으며 유일한 단점은 단순한 접근 방식으로 인해 많은 사람들이 자신의 방대한 기능을 발굴하는데 시간을 허비하지 않는다는 것입니다.

최근 MVC를 사용하여 프로젝트를 완료했으며 응용 프로그램 개발에 대한 디자인 접근 방식 (더 많은 제어, URL 정리, SOC 등)을 좋아하지만 WebForms가 제공 할 수없는 기능은별로 없습니다. 실제로 jQuery의 등장과 WebVC (MVC뿐만 아니라)와의 작업으로 인해 이러한 주장은 문제가되지 않았습니다. 그리고 사람들이 MVC가 MVP보다 우위에있는 관심사에 대해 이야기 할 때, 나는 객체 지향 프로그래밍에 대해 얼마나 많이 알고 있으며 추상화와 다형성의 원리를 얼마나 많이 사용하는지 묻습니다.

현재 두 기술을 모두 사용하는 것이 편하고 상황에 따라 선택하고 선택합니다. 솔직히 말해서, 그것은 당신에게 달려 있지만, 모든 사람들이 특정 기술이 무엇을 할 수 있는지 깊이 배우기 위해 시간을내는 것은 아니라는 것이 진실입니다.

프로그래밍 문제에 직면했을 때 종종 웹에서 답을 찾습니다. Webforms에는 거의 모든 작업에 관한 수많은 정보 / 구성 요소가 있습니다. MVC에서 온라인으로 더 적은 소스와 무언가를 만드는 데 필요한 추상화 계층으로 인해 한 번 할 수있는 일이 제한되었습니다. MVC 토탈은 Webforms가 아닌 개발자로서의 생산성을 떨어 뜨립니다. 그래서 지금은 MVC가 그것을 대체 할만 큼 성숙해질 때까지 웹 양식을 고수하고 있습니다.

글쎄, WebForms에는 더 많은 학습 리소스가 있습니다 (간단히 오래 되었기 때문에). "알지 못하는"새로운 프로그래머는 MVC와 같은 새로운 것들과는 달리이 오래된 기술에 관한 정보를 찾을 가능성이 높습니다 .

선임 / 경험이있는 프로그래머는 나이가 많고, 더 오래된 프로그램에 비해 프로그램에 더 오래 프로그래밍되어 있기 때문에 더 오래된 기술에 능숙 할 것입니다.

사람들이 WebForms 애플리케이션 에서처럼 MVC에 능숙 해 지도록 돈과 노력을 들이지 않는다면, 가능한 한 오랫동안 새로운 플랫폼으로의 업그레이드를 시도 할 것입니다.

따라서 몇 가지 물류 문제가 있습니다. MVC의 이점이 품질 및 배포 시간이 줄어든다는 것보다 비용을 능가합니까? WebForms로 작성된 사이트가 있다면 MVC를 통합하는 데 많은 노력과 비용이 듭니까?

이전 주석 작성자가 언급했듯이 MVC를 사용하면 WebForms와 동일한 수준의 컨트롤러 인터페이스를 얻을 수 없습니다. 나는 "사용자가 물건을 채우거나 배우지 못하도록하십시오"라는 측면에 모두 책임을지고 있지만, 팀이 작성하는 모든 것에 대한 패러다임을 고수하는 프로그램을 팀이 배포 / 구현하는 것은 여전히 ​​불합리한 일입니다.

이 두 기술 사이의 격차는 예전만큼 넓지 않다고 생각합니다.

• 웹 양식은 MVC가 사용하는 라우팅 엔진 (또는 매우 유사한 것)을 사용할 수 있습니다.
• 스크립트 관리자는 스크립트를 결합하고 CDN에서로드하며 스크립트로드를 지연시킬 수도 있습니다.

귀하의 질문에 직접 대답하기 위해 선호도 및 / 또는 프로젝트가 무엇인지 생각합니다. 그들은 개발에있어 상당히 다른 접근법을 취합니다. 개인적으로 저는 MVC로 나아가려고 노력하고 있지만 여전히 Webforms 작업을 즐깁니다. MVC 또는 Webforms 중 어느 것을 사용해야하는지에 대한 대답은 두 가지 기술을 모두 경험함으로써 결정하는 것이라고 생각합니다.