답변:
ASP.net MVC 의 주요 장점 은 다음과 같습니다.
렌더링 된 HTML을 완전히 제어 할 수 있습니다.
우려 사항 (SoC)을 깨끗하게 분리합니다.
수 있도록 테스트 주도 개발 (TDD)은 .
JavaScript 프레임 워크와 쉽게 통합
웹의 무국적 특성 설계에 따라
SEO를 가능하게하는 RESTful URL.
ViewState 및 PostBack 이벤트가 없습니다.
ASP.net Web Form 의 주요 장점 은 다음과 같습니다.
RAD 개발을 제공합니다
winform 개발에서 온 개발자를위한 쉬운 개발 모델.
ASP.NET Web Forms 및 MVC는 Microsoft에서 개발 한 두 가지 웹 프레임 워크입니다. 둘 다 좋은 선택입니다. 웹 프레임 워크 중 어느 것도 다른 프레임 워크로 대체되거나 단일 프레임 워크로 '병합'할 계획이 없습니다. 지속적인 지원 및 개발은 Microsoft와 병행하여 수행되며 어느 것도 사라지지 않을 것입니다.
이러한 각 웹 프레임 워크는 장점 / 단점을 제공하며 웹 응용 프로그램을 개발할 때 일부를 고려해야합니다. 웹 응용 프로그램은 두 기술 중 하나를 사용하여 개발할 수 있습니다. 특정 응용 프로그램의 개발이 한 기술을 다른 기술보다 더 쉽게 선택할 수 있으며 그 반대도 마찬가지입니다.
ASP.NET 웹 양식 :
ASP.NET MVC :
인증, 권한 부여, 구성, 컴파일 및 배포는 두 웹 프레임 워크간에 공유 되는 모든 기능입니다 .
고전적인 ASP를 기억할만큼 나이가 든 사람은 HTML과 자바 스크립트가 혼합 된 코드로 페이지를 여는 악몽을 기억할 것입니다. 심지어 가장 작은 페이지조차도 도대체 무슨 일이 있었는지 파악하기가 어려웠습니다. 나는 틀릴 수 있고, 나는 희망하지만 MVC는 그 나쁜 시절로 돌아가는 것처럼 보입니다.
ASP.Net이 등장했을 때 구세주가되어 콘텐츠에서 코드를 분리하고 웹 디자이너가 HTML을 만들고 코드 작성자가 코드를 작성하도록 할 수있었습니다. ViewState를 사용하지 않으려면 끄십시오. 어떤 이유로 코드를 사용하고 싶지 않다면 코드를 클래식 ASP처럼 html 안에 넣을 수 있습니다. PostBack을 사용하지 않으려면 처리를 위해 다른 페이지로 리디렉션했습니다. ASP.Net 컨트롤을 사용하지 않으려면 표준 html 컨트롤을 사용했습니다. 컨트롤에서 ASP.Net runat = "server"를 사용하지 않으려면 Response 객체를 조사 할 수도 있습니다.
이제 위대한 지혜를 가진 사람 (아마도 고전적인 ASP를 프로그래밍 한 적이없는 사람)은 코드를 내용과 혼합하는 시대로 돌아가서 "문제의 분리"라고 할 시간을 결정했습니다. 물론 더 깨끗한 HTML을 만들 수는 있지만 고전적인 ASP로 가능합니다. "보기 내에 코드가 너무 많으면 올바르게 프로그래밍하지 않는다"고 말하는 것은 "기본 ASP에서 체계적이고 주석이 달린 코드를 작성한 경우 ASP.NET보다 훨씬 깨끗하고 낫습니다"라고 말하는 것과 같습니다.
코드를 내용과 혼합하는 것으로 돌아가고 싶다면 그러한 종류의 개발을 위해 훨씬 성숙한 환경을 가진 PHP를 사용하여 개발하는 것을 볼 것입니다. ASP.NET에 많은 문제가 있다면 왜 그 문제를 해결하지 않습니까?
마지막으로 새로운 Razor 엔진은 HTML과 코드를 구분하기가 더 어렵다는 것을 의미합니다. 적어도 ASP에서 <% 및 %> 태그를 열고 닫을 수는 있지만 이제는 @ 기호 만 표시됩니다.
PHP로 옮겨 다른 사람이 코드를 내용과 다시 분리 할 때까지 10 년을 더 기다려야 할 때입니다.
PHP 나 JSP와 같은 다른 개발자들과 함께 일하고 있다면 (그리고 난 레일을 추측하고있다), 페이지에 대한 변환이나 공동 작업이 훨씬 더 쉬워 질 것이다. 사방 이벤트 및 제어.
MVC의 문제점은 "전문가"조차도 많은 귀중한 시간을 소비하고 많은 노력이 필요하다는 것입니다. 비즈니스는 기본 기술인 "작동하는 빠른 솔루션"의 기본 기술에 의해 좌우됩니다. WebForms는 시간과 비용을 절약하는 RAD 기술입니다. 비즈니스에 더 많은 시간이 필요한 것은 허용되지 않습니다.
가장 큰 장점은 모델, 뷰 및 컨트롤러 레이어를 명확하게 구분하는 것입니다. 처음부터 좋은 디자인을 홍보하는 데 도움이됩니다.
ASP.Net보다 MVC에서 어떤 이점도 보지 못했습니다. 10 년 전 Microsoft는 MVC에 대한 답변으로 UIP (User Interface Process)를 개발했습니다. 플롭이었다. 우리는 당시 UIP로 대규모 프로젝트 (4 명의 개발자, 2 명의 디자이너, 1 명의 테스터)를 수행했으며 악몽이었습니다.
과대 광고를 위해 악대 차로 뛰어 들지 마십시오. 위에 나열된 모든 장점은 이미 Asp.Net에서 사용할 수 있습니다 ( Asp.Net 4의 새로운 기능 [ Asp.Net 4의 새로운 기능 ]).
Asp.Net을 사용하는 개발 팀 또는 단일 개발자 가족이라면이를 고수하고 아름다운 제품을 신속하게 만들어 고객 (근무 시간을 지불하는 고객)을 만족 시키십시오. MVC는 귀중한 시간을 먹고 Asp.Net과 동일한 결과를 생성합니다 :-)
프란시스 샤나 한,
왜 부분 포스트 백을 "넌센스"로 부르나요? 이것은 Ajax의 핵심 기능이며 Atlas 프레임 워크 및 Telerik과 같은 멋진 타사 컨트롤에서 매우 잘 활용되었습니다.
나는 viewstate에 관한 당신의 요점에 동의합니다. 그러나 개발자가 viewstate를 사용하지 않도록 신중하게 설정하면 렌더링되는 HTML의 크기가 크게 줄어들어 페이지가 가벼워집니다.
HTML 서버 컨트롤 만 ASP.NET Web Form 모델에서 이름이 바뀌고 순수한 HTML 컨트롤은 아닙니다. 그것이 무엇이든간에, 이름 변경이 완료되면 왜 그렇게 걱정됩니까? 클라이언트 측에서 많은 자바 스크립트 이벤트를 처리하고 싶지만 웹 페이지를 똑똑하게 디자인하면 원하는 모든 ID를 얻을 수 있습니다.
ASP.NET Web Forms조차도 XHTML 표준을 충족하며 부풀어 오르지 않습니다. 이것이 왜 MVC 패턴이 필요한지에 대한 정당화가 아닙니다
다시, 왜 AXD Javascript에 신경 쓰십니까? 왜 아파요? 이것은 다시 정당한 정당화가 아닙니다
지금까지 고전적인 ASP.NET 웹 양식을 사용하여 응용 프로그램을 개발하는 팬입니다. 예를 들면 : 드롭 다운 목록이나 그리드 뷰를 바인딩하려면 최대 30 분과 20 줄 이하의 코드가 필요합니다 (최소한). 그러나 MVC의 경우 개발자에게 그것이 얼마나 고통 스러운지 이야기하십시오.
MVC의 가장 큰 단점은 ASP 시대로 돌아가는 것입니다. 서버 코드와 HTML을 섞는 스파게티 코드를 기억하십니까? 오 마이 갓, 자바 스크립트, HTML, JQuery, CSS, 서버 태그가 혼합 된 MVC aspx 페이지를 읽으십시오.
webforms에서는 viewstate, eventvalidation 등의 태그를 제외하고 PageAdapters로 제거 할 수있는 거의 모든 태그를 직접 HTML로 직접 렌더링 할 수 있습니다. 아무도 HTML 렌더링 출력이 나쁜 GridView 또는 다른 서버 측 컨트롤을 사용하도록 강요하지 않습니다.
MVC의 가장 큰 장점은 SPEED라고합니다.
다음은 우려의 강제 분리입니다. 그러나 컨트롤러 / 액션 안에 전체 BL 및 DAL 로직을 넣는 것은 금지되지 않습니다! 웹폼 (예 : MVP 패턴)에서도 수행 할 수있는 뷰 분리입니다. 사람들이 mvc에 대해 언급 한 많은 것들이 webforms에서 수행 될 수 있지만 몇 가지 추가 노력이 필요합니다.
주요 차이점은 요청이 보이지 않고 컨트롤러에 온다는 것입니다.이 두 레이어는 webforms와 같은 부분 클래스를 통해 연결되지 않고 분리됩니다 (aspx + 코드 숨김)
MVC를 사용하면 한 페이지에 둘 이상의 양식을 만들 수 있습니다. 내가 아는 작은 기능이지만 편리합니다!
또한 MVC 패턴으로 인해 코드를 쉽게 유지 관리 할 수 있다고 생각합니다. 몇 달 후에 다시 방문 할 때
runat="server"생각합니다.
MVC 컨트롤러 :
[HttpGet]
public ActionResult DetailList(ImportDetailSearchModel model)
{
Data.ImportDataAccess ida = new Data.ImportDataAccess();
List<Data.ImportDetailData> data = ida.GetImportDetails(model.FileId, model.FailuresOnly);
return PartialView("ImportSummaryDetailPartial", data);
}MVC보기 :
<table class="sortable">
<thead>
<tr><th>Unique Id</th><th class="left">Error Type</th><th class="left">Field</th><th class="left">Message</th><th class="left">State</th></tr>
</thead>
<tbody>
@foreach (Data.ImportDetailData detail in Model)
{
<tr><th>@detail.UniqueID</th><th class="left">@detail.ErrorType</th><th class="left">@detail.FieldName</th><th class="left">@detail.Message</th><th class="left">@detail.ItemState</th></tr>
}
</tbody></table>얼마나 힘들어요? ViewState, BS 페이지 수명주기 없음 ... 순전히 효율적인 코드입니다.
내가 찾은 주요 이점은 프로젝트를보다 테스트 가능한 구조로 만듭니다. 이것은 webforms (MVP 패턴)로도 쉽게 수행 할 수 있지만 개발자는 이것을 이해해야합니다.
Webform과 MVC는 모두 다른 영역에서 탁월한 실행 가능한 도구입니다.
B2B / LOB 앱을 주로 개발할 때 개인적으로 웹 양식을 사용합니다. 그러나 단위 테스트를 위해 95 % 이상의 코드 적용 범위를 달성 할 수있는 MVP 패턴으로 항상이를 수행합니다. 이것은 또한 우리가 webcontrols의 속성에 대한 테스트를 자동화 할 수있게합니다.
bool IMyView.IsAdminSectionVisible{
get{return pnlAdmin.Visible;}
get{pnlAdmin.Visible=value;}
}) 나는이 수준의 테스트가 내 모델을 오염시키지 않고 MVC에서 쉽게 달성 할 수 있다고 생각하지 않습니다.