MVC보다 ASP.NET WebForms를 선호하는 경우

Webforms vs. MVC는 현재 뜨거운 주제 인 것 같습니다. 내가 아는 모든 사람들은 MVC가 다음 대단한 것이라고 선전합니다. 내 약간의 손놀림으로 볼 때 괜찮아 보이지만 웹 양식의 끝이 아닐 것 같습니다.

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

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

팀은 웹 양식을 알고 있으며 MVC에 대한 속도를 높일 시간이 없습니다. 생성되는 코드는 품질이 좋지 않을 수 있습니다. MVC의 기초를 배우고 나서해야 할 복잡한 페이지를 수행하는 것은 매우 다른 일입니다. 학습 곡선이 높기 때문에이를 예산에 포함시켜야합니다.

웹 양식으로 모두 작성된 대규모 웹 사이트가 있다면 웹 양식으로 새 페이지를 만드는 경향이있을 수 있습니다. ” 사이트에 매우 다른 두 가지 유형의 페이지가 있습니다.

여기서는 이것이 전부 또는 전혀 접근하지 않는다고 말하는 것은 아니지만 두 가지가 모두 분할되어 있으면 코드를 유지하기가 더 어려워집니다. , 특히 팀원 모두가 MVC에 익숙하지 않은 경우입니다.

저희 회사는 최근 MVC를 사용하여 세 페이지의 테스트 페이지를 수행했습니다. 우리는 앉아서 디자인했습니다. 우리가 만난 한 가지 문제는 대부분의 화면에 동일한 페이지에보기 및 편집 기능이 있습니다. 결국 페이지에 둘 이상의 양식이 필요하게되었습니다. 마스터 페이지를 사용하지 않는 경우를 제외하고는 별다른 의미가 없습니다. 웹 양식 페이지와 MVC 페이지가 공통된 모양과 느낌을 위해 동일한 마스터 페이지를 사용할 수 있도록 수정해야했습니다. 이제 추가 중첩 레이어가 있습니다.

적절한 MVC 분리를 따르기 위해 이러한 페이지에 대해 완전히 새로운 폴더 구조를 만들어야했습니다.

3 페이지에 대한 파일이 너무 많다고 생각했지만 그게 제 개인적 의견입니다.

제 생각에는 MVC를 사용하기 위해 사이트를 업데이트하는 데 투자 할 시간 / 돈이 없다면 MVC보다 웹 양식을 선택하는 것입니다. 현재 가지고있는 웹 양식보다 더 나을 수는 없습니다. 더 나쁜 것은이 기술이 엉망이 된 경우 회사의 실패에 대비할 수도 있다는 것입니다. 고위 경영진이 알고있는 것보다 열등하다고 생각할 수 있기 때문입니다.

댓글

• 좋은 답변입니다. 개인적인 경험에 감사를 표했기 때문에 +1을주었습니다. 그러나 이것은 제가 피하도록 요청한 개발자의 경험 / 기술 부족으로 인한 실패입니다. . Microsoft가 단순히 MVC의 학습 곡선에 대한 두려움 때문에 폐기 된 기술을 표시하지 않을 것이라고 확신하지 않습니다. 그럴 수도 있지만 아직은 아닙니다. ‘ 확신했습니다.
• @ P.Brian.Mackey-저는 ‘ 양식 개발이 MVC보다 빠르다고 말하지 않았습니다. 당신은 그 주장을 그만두라고 요청했습니다. 직원 교육에 필요한 시간과 비용을 주장하는 것은 다른 주장입니다. MS는 ‘ 큰 이유에서 웹 양식을 구식으로 표시하지 않았습니다. 엔터프라이즈 클라이언트는 웹 양식에서 웹 클라이언트를 개발하는 데 수년을 보냈고 이겼습니다. ‘ 업데이트를 위해 시간과 돈을 투자해야한다고 친절하게 생각하지 마십시오.
• @Raynos-팀원 모두가 MVC에 능숙하고 회사에서 새 프로젝트를 시작했다면 웹 양식을 선택하는 사람을 볼 수있는 유일한 이유는 개인적인 선택입니다.
• 두 기술을 모두 잘 알고 있습니다. 내 모든 웹 프로젝트는 mvc로 수행되며 최선의 접근 방식이 무엇이든 할 수있는 자유 통치가있는 회사에서 일합니다. 저는 항상 MVC를 선택합니다.
• Webforms로 시작했고 MVC를 발견 한 후에는 MVC로 전환했습니다. 저는 ‘ 누군가 웹 양식을 어떻게 방어 할 수 있는지 모릅니다. 페이지 라이프 사이클과 전체 페이지에 대한 하나의 양식? 장난 해? Yahoo sitebuilder는 아마도 의도 된 고객 이었지만 ‘ 그 쓰레기를 원하지 않았습니다.

저는 3 년 동안 ASP .Net WebForms 애플리케이션을 개발했고, MVC 튜토리얼을 수행 한 지 하루 만에 매각되었습니다. MVC는 거의 항상 더 나은 솔루션입니다. 그 이유는 무엇입니까?

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

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

Comments

• +1 여러 형태를 지적합니다. 또한 HTML 웹 양식이 생성하는 것은 대부분 SEO 친화적이지 않다는 사실입니다 (예 : 페이지 상단의 viewstate의 큰 덩어리).
• 이 답변에 100 % 동의해야합니다. 결국 WebForms는 클라이언트 측 (html / 브라우저)에서 작업을 훨씬 더 어렵게 만듭니다. 당신은 말 그대로 어떤 일을하기 위해 틀과 싸워야합니다. aspx 페이지는 일반적으로 cshtml 페이지보다 서버 컨트롤로 인해 훨씬 더 많은 코드로 끝납니다. @ šljaker ViewState를 끄고 서버 컨트롤을 사용하지 않는 경우 ‘ 그 시점에서 WebForms 대부분을 포기한 것입니다. 저는 ‘이 주장이 특히 설득력이 있다고 생각하지 않습니다.
• WebForms에서 일반 HTML 컨트롤을 사용할 수 있으며 아무도 서버 컨트롤을 사용하도록 강요하지 않습니다. 완전한 상태 비 저장 웹 양식을 가질 수 있으며 아무도 ViewState를 사용하도록 강요하지 않습니다. Webforms에서 전체 ajax 및 jQuery를 사용할 수 있으며 아무도 jQuery 사용을 제한하지 않습니다. URL 라우팅을 구현할 수 있으며 아무도 정적 파일 기본 URL을 사용하도록 강요하지 않습니다. CSS로 페이지를 수동으로 그리는 것은 MVC가 필요한만큼의 시간을 소비합니다. Webform에서 직접 HTML 페이지를 디자인 할 수 있습니다.
• @mjb : ‘ 서버 컨트롤, ViewState 등을 사용하지 않는 경우 WebForms를 사용하는 이유 MVC가 ‘하고있는 일에 더 가깝습니까? ‘ 마치 트랙터를 운전하여 출근하지만 오프 로딩을하지 않거나 삽 / 호미 또는 스태빌라이저 바를 사용하지 않는 것과 같습니다. 그 시점에서 왜 차를 사용하지 않습니까?
• @Tjaart ASPNET 페이지에서 여러 양식을 가질 수 없다는 것은 옳지 않습니다.ASPNET 페이지에서 원하는만큼의 양식을 가질 수 있지만 runat = ” server “가있는 양식-하나의 서버 양식 만 가질 수 있습니다. 속성.

Scott Guthrie , Microsoft의 MVC 전문가 . 그리고 아마도이 질문에 답할 수있는 가장 자격을 갖춘 사람 일 것입니다. 그는 친절하게 대답했습니다.

“다른 고객은 다른 프로그래밍 접근 방식을 찾고 있으며 많은 사람들이 WebForms를 좋아하고 훌륭하다고 생각합니다. 다른 사람들은 MVC를 좋아하고 이것이 우리가 두 가지 모두에 투자하는 이유입니다. “

그래서 이것은 기술적 인 문제가 아니라고 말합니다. 당신이 원한다면 그것은 “소프트 이슈”에 가깝습니다. 개인적 선호도 중 하나입니다. 여러 분이 말씀하신 내용과 일치합니다.

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

댓글

• Scott Guthrie가 발명 한 ASP.NET 용 MVC 프레임 워크는 2006/7 년에 런던에서 시애틀로 돌아 오는 비행 중에 있습니다. 생각해 보면 그는 .NET도 거의 발명했습니다 ( en.wikipedia.org/wiki/Scott_Guthrie ). 그를 ” 전문가 “라고 부르는 것은 엄청난 과소 표현입니다 .-)
• 그 ‘ Scott Guthrie의 훌륭한 정치적 답변입니다. 그가 자신의 웹 애플리케이션에 투자하고 있다면 ‘ MVC 프로젝트와 MVC에서 수행 할 수없는 ‘ 모든 것을 볼 수있었습니다. Silverlight는 대체품이 될 것입니다. ‘ 이것을 WebForms에 대한 부정적인 코멘트로 받아들이지 마십시오. WebForms는 Telerik에서 만든 것과 같은 타사 구성 요소를 활용할 수있는 작은 범위의 내부 응용 프로그램에 적합하다고 생각합니다. 저는 ‘ Microsoft가 두 기술을 모두 발전 시켜서 기쁩니다.
• ” Scott Guthrie는 ASP 용 MVC 프레임 워크를 발명했습니다. 비행 중 .NET ” MVC가 정말 상식적이라고 생각합니다. 저는 ‘ Scott Guthrie를 모르지만 ‘ MVC가 ASP.NET에서 구현 될 수있는 방법에 대해 잘 알고 있었을 것입니다. 한동안 긴 비행을 사용하여 개념 증명으로 베어 본 프로토 타입을 구현했습니다.
• ” 이것이 우리가 둘 다에 투자하는 이유입니다. ” 그리고 웹 양식이 감소하기 시작하면 최종적으로 죽은 제품에 투자하는 것이 비즈니스에 가장 이익이되지 않기 때문에 무자비하게 양식을 삭제합니다.
• 때까지 그것은 더 이상 학교에서 가르치지 않으며, 수년 동안 항상 비즈니스 세계에 적용될 것입니다. 대학과 고등학교는 vb.net에서 소개 및 고급 과정을 계속 제공합니다. 아무데도 가지 않습니다 !!!

이것은 답변이 많지만 답이없는 오래된 질문입니다. 내가 목록에 올릴 것으로 예상했던 대답이있었습니다.

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

• 최신 프로그래밍으로 웹 응용 프로그램을 제대로 빌드하려는 경우 ASP.NET MVC를 사용하십시오. ASP.NET 플랫폼에 대한 규칙 및 업계에서 채택한 패턴. 단점은 HTML과 클라이언트 측 리소스 (Javascript, CSS)가 어떻게 작동하는지 알 수있을뿐만 아니라 학습 곡선이 가파르지만 파악하면 갑자기 끝나는 MVC 프로그래밍 사고 방식을 높일 수 있습니다.
• GUI 중심, RAD (Rapid Application Development) , 드래그 앤 드롭 방식으로 매우 빠르게 프로토 타이핑 (예 : 푸시 버튼 / 데이터 그리드 동작이 15 분 이내에 연결됨), 솔루션은 지원 대상이 아닙니다. 또는 GUI 또는 Windows Forms 개발에 대한 배경 지식이 있고 웹에 대한 지식.

그러나 이것을 제대로 살펴 보려면 각각의 역사를 이해해야합니다.

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

전체적인 접근 방식은 개발자에게 Windows 응용 프로그램 개발과 매우 유사하지만 인터넷 서비스의 힘으로 두 가지 장점을 모두 제공하는 것이 었습니다.아이디어는 VB6 / WinForms “Form”(윈도우)과 마찬가지로 웹 페이지는 폼입니다 (윈도우처럼 참조) 그리고이 양식에서 레이블, 텍스트 상자, 데이터 그리드, 버튼 및 VB / WinForms GUI 개발자가 익숙한 기타 항목을 끌어서 놓을 수 있습니다.

버튼을 드래그 앤 드롭 한 후 디자이너에서 버튼을 두 번 클릭하고 코드 편집기에서 붐을 일으켜 “클릭 할 때 수행 할 작업”을 양식에 알려줍니다. “이벤트가 발생합니다. 이게 바로 Windows GUI 개발자가 VB6의 GUI 도구와 경쟁 도구를 사용하여 소프트웨어를 만든 방법입니다. 지금은 코드가 서버에서 실행 중입니다. 와우!

2002 년 기술이었습니다. 인터넷에 대한 답으로서 당시에는 놀랍고 아름답습니다. – RAD 개발 을위한 GUI 솔루션을 사용하여 힘을 얻었습니다. 달성해야 할 비즈니스 목표를 가진 복잡한 소프트웨어 개발자의 세계에.

불행히도이 프로그래밍 모델은 Windows GUI 프로그래밍의 은유를 너무 강조하여 필요한 구현 세부 사항의 부담을 수반합니다. , 모든 귀찮은 수하물 NEC 이벤트 수명주기를 수용하고 이러한 드래그 앤 드롭 구성 요소 및 컨트롤이 출력하는 간단한 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에서는 구성 요소가 개별적으로 테스트되도록 설계되지 않았고 전체 개발 출력이 페이지 양식 과 비즈니스 논리와 프레젠테이션 논리가 깊숙이 얽혀있는 이벤트 수명주기를 중심으로 돌아가므로 테스트하기가 어려웠습니다.

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

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

ASP.NET MVC 개발자는 서버 측 아키텍처와 싸우지 않고도 풍부한 Javascript 라이브러리와 클라이언트 측 템플릿 기술을 활용하는 집에서 느낄 수 있습니다. 이것은 원래 ASP의 경우가 아닙니다.NET Web Forms, Web Forms는 HTML이나 스크립트를 전혀 보지 않기를 원하기 때문입니다. 단, 정말로해야 하는 경우를 제외하고는주의해야합니다. .

댓글

• 이것은 좋은 대답이지만 # 1과 # 2는 틀 렸습니다 (WF는 데이터의 위치를 알기 위해 구성 요소가 필요하지 않습니다. 이는 옵션이며 렌더링하는 ASP 태그를 지원하기 위해 ASPX 파일에 항상 HTML을 추가했습니다. 개발자 용이 아닌 ASP 기능에 액세스하려고하지 않는 한 깊이 파고 컨트롤과 싸울 필요가 없었습니다. 가장 큰 포인트는 테스트 가능성과 디자인 패턴입니다.)

나는 완전하고 완전한 전 환자입니다. ASP.NET MVC로 전환하고 다시 살펴 보지 않았습니다. 그래도 여전히 매우 큰 WebForms 앱을 여러 개 유지해야한다고 말했습니다. 여기에 대해 설명하겠습니다.

WebForms
심각하게 무거울 때 사용합니다. 그리드와 관련이 있습니다. 표 형식에 잘 맞는 간단한 데이터 세트가 있고 사용자가 레코드를 업데이트 할 수있는 간단한 방법을 제공하려는 경우 그리드 컨트롤이 정말 좋습니다. 예, MVC 4에는 훌륭하게 사용할 수있는 멋진 Ajax 목록 유형이 있다는 것을 알고 있지만, 우리 비즈니스에서는 종종 어제 실행되는 것을 가져와야하며 좋은 구식 그리드가 훌륭하게 작동하고 사용자는 기뻐합니다. 글리로 그리드를 탭할 수 있습니다. 저에게는 이것이 바로 WebForms의 가장 좋은 점입니다.하지만 Ryan 이 지적했듯이 WebForms는 양쪽을 모두 플레이하기 때문에 시간이 엉망이 될 수 있습니다. 멋진 코드 숨김 파일에서 울타리의. 모든 컨트롤러 유형의 항목을 뷰와 혼합 된 상태로 유지하려면 장미와 가시를 동시에 사용할 수 있습니다.

MVC
직접 롤링하고 싶고 처음부터 애플리케이션을 시작할 기회가있을 때이 옵션을 사용하십시오. 명확하게 정의 된 MVC 응용 프로그램을 갖는 것은 시작하는 데 약간 더 많은 작업이 필요하지만 유지 관리의 이점은 초기 설정 비용보다 큽니다. 흥미로운 Ajax 상호 작용을하고 싶다면 깨끗한 URL과 경로와 같은 코드를 사용하여 모델을 작성하고 앱의 전체 흐름을 제어 할 수있는 것을 선호한다면 이것이 확실히 갈 길입니다. 처음에는 이것이 그린 필드 앱을위한 더 나은 옵션이라고 생각합니다.

결론적으로 나에게는 그리드와! 그리드가 있습니다. 🙂

댓글

• “의 양면 재생과 함께 제공되는 멋진 사진을위한 +1 멋진 코드 숨김 파일에서 차단 “.
• 이 파일은 매우 유용합니다. 저는 ‘ 매우 무거운 그리드 기반 앱을 수행하고 있으며 ‘ 실버 라이트, xbap을 배제했으며 이 둘.

내 경험 :

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

이후 그 경험으로 저는 웹 양식을 사용하여 다른 앱을 작성해 보았습니다. 웹 양식이 개발자가 “html, javascript 및 css를 사용하는 응용 프로그램을 개발하고 있다는 현실로부터 개발자를 보호하려고 시도하는 방법에 대해 약 하루 동안 어려움을 겪었습니다.

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

jQuery와 같은 강력한 UI 프레임 워크의 가용성 매우 종종 부피가 큰 사전 제작 된 UI 구성 요소를 사용하기 위해 출력의 직접 제어를 포기하는 매력을 강조합니다.

댓글

• @JimG-Uhh , 데이터베이스에 흥미로운 연관성없이 레코드를 입력하고 그 사람이나 다른 사람이 다른 지점에서이를 읽고 / 인쇄하도록하는 사람이 포함 된 모든 것은 기본적으로 MVC 프레임 워크를 사용하여 스캐 폴딩 될 수 있습니다. 물론, 이는 ‘ 대부분의 앱이 아니지만 ‘ 설문지로 할 수있는 것보다 훨씬 더 많습니다. -1이 내 요점을 증명한다고 생각합니다.
• 그 ‘는 하루의 1/4입니다.
• 그러나 요구 사항이 ” 하나는 정보를 기록하고 다른 하나는 정보를 확인하는 역할이 두 가지가 필요한 앱이 필요합니다. ‘ 어떻게 생겼는지 신경 쓰세요. ” 예, 그렇습니다. ‘ 꽤 가능합니다.
• 죄송합니다. 데이터를 입력하고 데이터를 볼 수있는 웹 양식 앱을 개발하는 것은 매우 간단하여 몇 시간 안에 완료 할 수 있습니다. MVC 앱, 컨트롤러,보기 및 작업의 구조를 만드는 데는 같은 시간이 걸리지 만 완성 된 제품을 얻을 수는 없습니다.
• @Dementic 일반적으로 간단한 MVC 앱의 경우 모델을 빌드 한 다음 컨트롤러와 뷰를 스캐 폴드하거나 스캐 폴딩 된 컨트롤러 / 뷰를 생성합니다. 시간이 많이 걸리는 일은 없습니다.

내 배경이 Windows 개발이기 때문에 웹 양식을 선호합니다.

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

기본 REST를 추상화하는 것은 나쁘고 전체 포스트 백 모델은 나쁘고 html / css가 의존하는 방식은 나쁘다고 생각합니다. GUI 편집기의 상태가 나쁘고 마법사 나 GUI와 같은 항목에 대한 강조도 나쁘고 URL도 나쁩니다.

댓글

• 왜 그렇게 생각하는지 더 자세히 설명해 주시겠습니까?
• 기본 REST 추상화가 돌아 왔다고 생각합니다. 전체 포스트 백 모델이 돌아 왔습니다. html / css가 GUI 편집기에 의존하여 처리되는 방식이 나쁩니다. , 설정을위한 마법사 및 GUI와 같은 항목에 대한 강조가 나쁘고, URL이 나쁨 등

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

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

이제 최근까지 웹 프로젝트를 수행하지 않았고 WPF를 사용하여 일부 Windows 응용 프로그램을 구축했습니다.

몇 일 전에 저는 웹 사이트와 개발에 대한 생각 : 이번에는 MVC에 관한 것입니다. (나도 배워야했던 것 외에도 MVC를 선택했기 때문에 어디에서나 이야기했기 때문에) 프로젝트는 아직 개발 단계에 있습니다. / p>

그래서 내가 찾은 두 가지의 주요 차이점은 다음과 같습니다 .-

• 윈도우 개발에서 온 사람에게는 웹 양식이 항상 유리할 것입니다. Windows 개발자를위한 .net 학습 곡선은 약간 가파르다

• 다른 기술의 웹 개발에서 온 사람에게는 MVC가 선호 될 것입니다. 모두 최신입니다.

• HTML 및 CSS에 대한 충분한 지식을 갖추고 있다면 MVC에서 개발이 더 쉽고 깔끔합니다.

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

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

아직이 스레드에 대한 기존 15 개의 답변 중에서 이러한 고려 사항이 제시된 것을 보지 못했지만 생각합니다. “고려할 가치가 있습니다.

내 경험으로 볼 때 Web Forms는 MVC보다 Win Forms 및 WPF와 더 유사합니다. 이 점을 감안할 때 팀이 이러한 종류의 기술에 가장 많은 경험이 있거나 Web Forms 프로젝트가 기존 (또는 동시에 개발 된) Win Forms와 동일한 데이터 세트에 대한 인터페이스를 제공 할 때 Web Forms를 선택하는 것이 좋습니다. WPF 프로젝트. 이렇게하면 애플리케이션 로직이 둘간에 매우 유사 할 수 있으므로 개발자가 프로젝트간에 더 쉽게 교차 할 수 있습니다.

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

댓글

• + 1 확실히 Webforms에 대한 합리적인 주장입니다. 저의 두려움은 팀이 새로운 것을 배우지 않기 위해 이러한 사고 방식을 따르는 것입니다. MVC는 팀에 익숙하지 않은 많은 패턴으로 가득 차 있습니다. 이러한 유형의 패턴을 학습하고 구현하면 SOLID 원칙을 더 잘 준수하여 전반적인 유지 관리 가능성이 향상됩니다. 이러한 입증 된 기술은 재사용 가능성의 진정한 열쇠이기도합니다.

사용하지 않는 이유 몇 년 전 MVC에 마이크로 소프트의 미성숙 한 기술이었다. 지난 몇 년 동안 우리는 이제 더 성숙한 버전 (4)을 사용하고 있으며 MS는 이것으로 어디로 가고 있는지 알아 낸 것 같습니다.그러나 버전 4에서 사용하려는 기능에는 Windows 2012 서버 (IIS8을 통한 웹 소켓)가 필요하기 때문에 MVC를 사용하여 주요 LOB 앱을 개발하는 것을 여전히 꺼려합니다. 1 년 후에는 더 많은 제 3 자 제어 기능을 사용할 수 있고 기술이 안정화되고이를 지원할 인프라를 확보 할 수 있기 때문에 MVC를 더 많이 수용 할 것이라고 생각합니다.

댓글

• Windows Server 2012에 필요한 이러한 기능 중 일부를 나열 해 주시겠습니까?

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

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

하나가 다른 것보다 낫다는 것이 아닙니다. 단순히 aproach 또는 프레임 워크 모두 장단점이 있습니다.

개인적으로 MVC 3를 선호합니다. 직접 경험해 보는 것이 좋지만 MVC의 프로그램은 깨끗하고, 재미 있고, 유연하고, 확장 가능하고, 안전하고, 구조화 된 방식이라고 말해야합니다.

감사합니다.

MVC 대신 WebForms를 선택하는 유일한 이유는 MVC보다 WebForms에 대한 타사 UI 컨트롤이 훨씬 더 많기 때문입니다. 나는 WebForms로 너무 많이 작업하고 신선하고 새로운 것으로 작업하고 싶지만 MS 상점에서 작업하고 싶기 때문에 MVC를 선택합니다. 🙂

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

이 WebForms 또는 MVC 코드입니까?

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

WebForms에서 찾은 유일한 제한은 의존성 주입 / 반전 제어, WebForms 페이지에는 매개 변수가없는 생성자가 있어야하므로 생성자 주입을 할 수 없습니다. 따라서 속성 주입을 사용해야합니다.이게 정말 큰 일입니까?

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

ASP.NET Webforms 는 직접 액세스를 통해 서버 측에서 클라이언트에 대한 많은 제어를 제공합니다. 기본적으로 뷰와 컨트롤러가 동일하므로 많은 힘과 대부분의 경우 엉망이됩니다.

ASP.NET MVC 는 긴밀한 결합을 분리하여보기와 컨트롤러를 분리합니다. .aspx 파일 및 웹 양식에 함께 제공되는 .aspx.cs 파일.

본질적으로 차이점은 데이터를 표시 하는 데 훨씬 많은 (일반적으로 모두) 처리하는 것입니다. 뷰 파일에 추가하고 비즈니스 로직과 나머지는 컨트롤러에 남겨 두어 규칙에 따라 둘 다 깔끔하게 유지하면서 웹 양식에서 허용하는 것보다 서로에 대한 액세스 권한이 적습니다.

댓글

• 그렇다면 언제 웹 양식이 MVC보다 선호되어야합니까? 이것은 원래 포스터 질문에 대한 답이 아닙니다.
• @WeekendWarrior-클라이언트에 대한 서버 측 액세스를 더 원할 때 웹 양식을 선택합니다. 코드에서 클라이언트 / 서버를 더 분리하려면 MVC를 선택하십시오. 하루가 끝나면 둘 다 똑같은 일을합니다. 경로 변경 필터는 MVC URL과 동일한 작업을 수행하며 웹 양식 코드를 별도의 중간 계층으로 이동하여 더 분리 할 수 있습니다. weblogs.asp.net/scottgu/archive/2010/01/24/ …
• 세 번째 요점과 관련하여 비즈니스 논리는 .aspx.cs 파일로 끝납니다. 이것은 개발자의 잘못이라고 생각합니다. ‘ 거기에있는 것이 / supposed / 아닙니다. Webforms에서 .aspx는 “보기 “이고 .aspx.cs는 ” controller “와 동등하며, 비즈니스 계층 또는 대략적인 비즈니스 파사드 계층을 폴링하여 UI에만 직접 관련된 코드를 처리하기위한 것입니다. 사람들이 .aspx.cs에 비즈니스 로직을 넣는다는 사실은 단지 잘못된 프로그래밍입니다. MVC의 뷰에 비즈니스 로직을 바로 넣을 수도 있습니다! MVC는 ‘ 이러한 것들을 강제로 분리하지 않습니다.
• 본질적으로 그는 여기에 게시 된 다른 답변보다 더 옳습니다. ASP.net은 Microsoft에서 만든 모듈 식 웹 기술 제품군의 기본 아이디어입니다. ASP.net MVC 모듈은 일시적으로 과장된 것일 수 있지만 마지막은 아니지만 모든 것이 ASP.net으로 시작하므로 ASP.net을 선택해야 할 때 MVC가 당신의 것이 아니라고 생각한다면, 아마도 뭔가에 더 많은 것을 할 수 있습니다 else OWIN 또는 …, 더 발전된 것 또는 작업을위한 자체 프레임 워크를 만들었습니다. ASP.MVC가 필요하지 않고 건너 뛰고 Owin 또는 Katana로 갈 수도 있지만 거기까지 asp를 사용할 때까지.net

제 생각에는 충분히 관련이 있고 올 때와 거의 동일한 기능을 가지고 있습니다.

훌륭한 WebForms 개발자는 훌륭한 MVC 개발자만큼 강력한 제품을 만들 수 있습니다. 그러나 스스로 MVC를 채택하도록 강요하려는 훌륭한 WebForms 개발자는 부족할 것입니다. WebForms에 기회를주는 훌륭한 MVC 개발자도 마찬가지입니다.

그들은 완전히 별개의 엔티티가 아니며 Microsoft가 두 가지 모두를 계속 지원하는 한 각각에 대해 뛰어난 개발자의 혼합 그룹을 계속 보게 될 것이라고 믿습니다.

이것은 우리가 사용하는 기술에 모두 능숙하다는 가정하에 개인적인 선택에 관한 것입니다. 저는 수년 동안 WebForms 디자인 접근 방식을 사용해 왔으며 유일한 단점은 “단순한 접근 방식으로 인해 많은 사람들이 시간을내어 웹폼의 방대한 기능을 발견하지 못한다는 것”입니다.

최근에 MVC를 사용하여 프로젝트를 완료했습니다. 응용 프로그램 개발에 대한 설계 접근 방식 (더 많은 제어, 깨끗한 URL, SOC 등)을 매우 좋아하지만 실제로는 제공하는 것이 많지 않습니다. , WebForms는 할 수 없습니다. 사실, jQuery의 출현과 WebForms (MVC 포함)와의 작동은 이러한 주장을 덜 문제로 만들었습니다. 사람들이 MVC가 MVP에 비해 갖는 이점으로서의 분리에 대해 이야기 할 때 저는 그들에게 얼마나 많은지 묻습니다. 그들은 객체 지향 프로그래밍에 대해 알고 있으며 추상화와 다형성의 원칙을 얼마나 많이 사용했는지 알고 있습니다.

현재 두 기술을 모두 사용하는 것이 편하고 상황에 따라 선택하고 선택합니다. 하지만 모든 사람이 특정 기술의 능력을 깊이 배우는 데 시간이 걸리는 것은 아닙니다.

댓글

• 계속 웹 양식의 방대한 기능. 대부분의 사람들은 웹 양식의 훈련 휠을보고이를 MVC와 비교하고 있습니다.
• 오늘날 HTML과 자바 스크립트 위에서 추상화를 배우는 것은 의미가 없습니다. 2013). ‘ 향후 기회에 좋지 않습니다. HTML 및 Java cript는 그대로입니다. 싸우는 것은 패배입니다.

프로그래밍 문제에 직면했을 때 웹을 자주 봅니다. 답변. Webforms에는 거의 모든 작업에 대한 수많은 정보 / 구성 요소가 있습니다. MVC에서는 온라인 소스가 적고 무언가를 만드는 데 필요한 추상화 계층으로 인해 한 번 할 수 있었던 일에 한계가 있습니다. MVC total은 개발자로서의 생산성을 저하시키는 반면 Webforms는 그렇지 않습니다. 따라서 지금은 MVC가이를 대체 할 수있을만큼 성숙해질 때까지 웹폼을 고수하고 있습니다.

글쎄, WebForms는 더 많은 학습 리소스를 사용할 수 있으며 (단순히 오래 되었기 때문에) “알고 있지 않은”새로운 프로그래머가 찾을 가능성이 더 높습니다. MVC와 같은 최신 기술과는 대조적으로이 오래된 기술에 관한 정보.

경험이있는 선임 프로그래머는 나이가 더 많고 이전 기술에 더 오래 프로그래밍했기 때문에 더 능숙 할 것입니다. 최신 버전에 있습니다.

사용자가 WebForms 애플리케이션 에서처럼 MVC에 능숙 해 지도록 돈과 노력을 들일 수 없다면, 의심 할 여지없이 새로운 버전으로의 업그레이드를 보류 할 것입니다. 가능한 한 오랫동안 플랫폼을 사용할 수 있습니다.

따라서 몇 가지 물류 문제가 있습니다. MVC의 이점이 품질 및 품질 저하 측면에서 비용보다 큽니다. 배포 시간? WebForms로 완전히 작성된 사이트가있는 경우 MVC를 통합하는 데 노력과 비용을 투자 할 가치가 있습니까?

이전 의견 작성자가 언급했듯이 MVC는 다음과 같은 수준의 인터페이스를 달성하지 못하게합니다. WebForms로 할 수있는 컨트롤러입니다. 저는 “사용자가 물건을 채우거나 배우지 못하도록합니다”라는 측면을 모두 선호하지만 팀이 작성하는 모든 내용에 대해 해당 패러다임을 열광적으로 고수하는 프로그램을 배포 / 구현하는 것은 여전히 불합리한 문제 일 수 있습니다.

이 두 기술 간의 격차가 예전만큼 크지 않다고 생각합니다.

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

귀하의 질문에 직접 답변하려면 선호도에 달려 있다고 생각합니다. 및 / 또는 프로젝트가 무엇인지. 둘 다 개발에 대해 상당히 다른 접근 방식을 취합니다. 개인적으로 저는 MVC로 이동하기 위해 노력해 왔지만 여전히 Webforms로 작업하는 것을 즐깁니다. MVC 또는 Webforms를 사용해야할지 여부에 대한 대답은 두 기술을 모두 경험하여 결정하는 것입니다.

댓글

• Webforms 및 MVC는 기본적으로 근본적으로 다른 웹 개발 태도를 권장합니다. 이것은 중요 이며 일부 개발자는 편차가 있습니다. ” 기본값 “에서. 두 가지 모두 동일한 작업을 수행하는 데 사용할 수 있습니다.