[asp.net-mvc] 내 옆에 아무도 ASP.NET MVC를 얻지 못합니까? [닫은]

Web Forms와 비교할 때 MVC는 HTML 생성에 대한 하위 수준의 접근 방식 이며 페이지 출력을보다 강력하게 제어하고 아키텍처 수준이 높은 고급 수준의 접근 방식입니다. Web Forms와 MVC를 캡처하고 고전적인 Web Forms 트랩에 속하지 않는 한 많은 상황에서 비교가 Web Forms를 선호한다고 생각하는 이유를 보여 드리겠습니다.

웹 양식

Web Forms 모델에서 페이지는 브라우저의 페이지 요청과 직접 일치합니다. 따라서 사용자를 서적 목록으로 안내하는 경우 “Booklist.aspx”라는 페이지가있을 수 있습니다. 해당 페이지에서 해당 목록을 표시하는 데 필요한 모든 것을 제공해야합니다. 여기에는 데이터 가져 오기, 비즈니스 로직 적용 및 결과 표시를위한 코드가 포함됩니다. 페이지에 영향을주는 아키텍처 또는 라우팅 논리가있는 경우 페이지의 아키텍처 논리도 코딩해야합니다. 우수한 Web Forms 개발에는 일반적으로 별도의 (단위 테스트 가능) DLL로 지원 클래스 세트 개발이 포함됩니다. 이 수업은 비즈니스 로직, 데이터 액세스 및 아키텍처 / 라우팅 결정을 처리합니다.

MVC

MVC는 웹 애플리케이션 개발에 대해보다 “건축적인”관점을 취합니다. 즉, 구축 할 표준화 된 스캐 폴드를 제공합니다. 또한 기존 아키텍처 내에서 모델, 뷰 및 컨트롤러 클래스를 자동으로 생성하기위한 도구를 제공합니다. 예를 들어, Ruby on Rails (여기서는 “Rails”만)와 ASP.NET MVC에서 웹 애플리케이션 아키텍처의 전체 모델을 반영하는 디렉토리 구조로 시작해야합니다. 뷰, 모델 및 컨트롤러를 추가하려면 Rails의 “Rails 스크립트 / 생성 스캐 폴드 {modelname}”(ASP.NET MVC는 IDE에서 유사한 명령을 제공함)과 같은 명령을 사용합니다. 결과 컨트롤러 클래스에는 색인 (표시 목록), 표시, 새로 작성 및 편집 및 삭제 (적어도 Rails에서는 MVC가 유사 함)에 대한 메소드 ( “Actions”)가 있습니다. 기본적으로이 “

디렉토리와 파일의 레이아웃은 MVC에서 중요합니다. 예를 들어 ASP.NET MVC에서 “Book”개체 의 Index 메서드에는 “Return View ();”라는 한 줄만있을 것입니다. MVC의 마법을 통해 책 모델을 책을 표시하는 코드를 찾을 수있는 “/View/Books/Index.aspx”페이지로 보냅니다. 논리가 조금 더 명확하고 덜 “매직”하지만 Rails의 접근 방식은 비슷합니다. MVC 앱 의 보기 페이지는 일반적으로 웹 양식 페이지보다 간단합니다. 라우팅, 비즈니스 로직 또는 데이터 처리에 대해 걱정할 필요가 없기 때문입니다.

비교

MVC의 장점은 문제를 명확하게 구분하고보다 생산적인 HTML / CSS / AJAX / 자바 중심의 모델을 생성하는 것입니다. 이를 통해 테스트 가능성이 향상되고보다 표준화 된 디자인이 제공되며보다 “Web 2.0″유형의 웹 사이트가 열립니다.

그러나 몇 가지 중요한 단점도 있습니다.

첫째, 데모 사이트를 만들기가 쉽지만 전체 아키텍처 모델에는 상당한 학습 곡선이 있습니다. 그들이 “컨벤션 오버 컨벤션 (Convention Over Configuration)”이라고 말하면, 배우는 책의 관습이 중요하다는 것을 알기 전까지는 좋은 소리가납니다. 또한, 당신이 있기 때문에 뭐가 어떻게 돌아가는지 파악하기 위해 비트 미치게 자주 하는 명시 적으로 호출보다는 마법에 의존는. 예를 들어 “Return View ();” 위에 전화? 다른 행동에서 똑같은 전화를 찾을 수 있지만 다른 장소로갑니다. MVC 규칙 을 이해하면왜 이런 일이 일어나는지 알 것입니다. 그러나 확실히 좋은 이름 지정 또는 이해하기 쉬운 코드의 예에 해당되지는 않으며 새로운 개발자가 Web Forms보다 선택하기가 훨씬 어렵습니다. 올해 MVC와 생산성의 차이가 두드러졌습니다 (Web Forms에 유리함). BTW, Rails는 이와 관련하여 조금 더 나아졌지 만 Ruby on Rails는 동적으로 명명 된 메소드를 사용하여 약간의 사용이 필요합니다.

둘째, MVC는 사용자가 기존 CRUD 스타일 웹 사이트를 구축하고 있다고 암시합니다. 아키텍처 결정 및 특히 코드 생성기는 모두 이러한 유형의 웹 응용 프로그램을 지원하도록 구축되었습니다. CRUD 응용 프로그램을 구축 할 때 입증 된 아키텍처를 채택하거나 아키텍처 설계를 싫어하는 경우 MVC를 고려해야합니다. 그러나 CRUD 이상을 수행하거나 아키텍처와 합리적으로 경쟁력이 있다면 MVC는 기본 라우팅 모델을 실제로 마스터 할 때까지 직선 자켓처럼 느껴질 수 있습니다 (WebForms 앱에서 라우팅하는 것보다 훨씬 더 복잡합니다). 그럼에도 불구하고, 나는 항상 모델과 싸우고 예기치 않은 결과에 대해 걱정하는 것처럼 느꼈습니다.

셋째, Linq에 신경 쓰지 않는다면 (Linq-to-SQL이 사라질까 두려워하거나 Linq-to-Entities가 과도하게 생성되고 전력이 부족하다는 것을 알기 때문에) 원하지 않습니다. Linq 주위에 ASP.NET MVC 스캐 폴딩 도구가 구축되어 있기 때문에이 길을 걸을 수 있습니다. Rails의 데이터 모델은 또한 SQL에 익숙한 경우 (특히 TSQL 및 저장 프로 시저에 정통한 경우) 달성 할 수있는 것과 비교할 때 매우 어색합니다.

넷째, MVC 지지자들은 종종 MVC 뷰가 웹의 HTML / CSS / AJAX 모델에 더 가깝다고 지적합니다. 예를 들어, 내용을 바꾸고 HTML 컨트롤에 배치하는 Vew 페이지의 작은 코드 호출 인 “HTML Helpers”는 Web Forms 컨트롤보다 Javascript와 통합하기가 훨씬 쉽습니다. 그러나 ASP.NET 4.0에는 컨트롤의 이름을 지정하는 기능이 도입되어 이러한 이점을 크게 제거했습니다.

다섯째, MVC 순수 주의자들은 종종 Viewstate를 무시합니다. 어떤 경우에는 그렇게 할 수 있습니다. 그러나 Viewstate는 훌륭한 도구이자 생산성에 도움이 될 수 있습니다. 비교해 보면 MVC 앱에서 타사 웹 컨트롤을 통합하는 것보다 Viewstate를 처리하는 것이 훨씬 쉽습니다. MVC의 제어 통합이 쉬워 질 수 있지만, 내가 본 모든 현재의 노력은 이러한 제어를 뷰의 컨트롤러 클래스에 다시 연결하기 위해 (어떤 정도의 거친) 코드를 작성해야합니다 (즉 , MVC 모델 을 해결 하기 위해) ).

결론

나는 여러 가지면에서 MVC 개발을 좋아한다 (장거리에서는 Rails를 ASP.NET MVC보다 선호하지만). 또한 ASP.NET MVC가 ASP.NET Web Forms의 “반 패턴”이라는 생각의 함정에 빠지지 않는 것이 중요하다고 생각합니다. 그것들은 다르지만 완전히 외계인은 아니며 두 가지를위한 공간이 있습니다.

그러나 Web Forms 개발을 선호 합니다. 대부분의 작업 에서는 작업을 수행 하기가 더 쉽습니다 (CRUD 양식 집합 생성 제외). MVC는 또한 어느 정도 과도한 이론 으로 인해 어려움을 겪고있는 것으로 보인다 . 실제로 페이지 지향 ASP.NET을 알고 있지만 MVC를 시도하는 사람들이 SO에 대해 여기에서 제기 한 많은 질문을 살펴보십시오. 예외없이, 개발자가 농구를 뛰어 넘거나 거대한 학습 곡선을 견뎌 내야 기본 작업을 수행 할 수 없다는 사실을 알게되면 치아가 많이 나옵니다. 이것은 나의 책에서 MVC 우수 웹 양식을 만드는 것입니다 : MVC는 당신이 지불하게 실제 가격 , 또는 더 나쁜 아직 조금 더 테스트 용이성을 얻기 위해 간단하게 볼 수 멋진 당신은을 사용하고 있기 때문에최신 기술.

업데이트 : 의견 섹션에서 크게 비판을 받았습니다. 일부는 상당히 공평합니다. 따라서 나는 몇 달 동안 Rails와 ASP.NET MVC를 배우면서 다음 큰 일을 실제로 놓치지 않았는지 확인했습니다! 물론, 질문에 대한 균형 잡힌 적절한 답변을 제공하는 데 도움이됩니다. 위의 답변은 의견이 일치하지 않는 경우를 대비하여 초기 답변을 크게 재 작성 한 것입니다.

MVC를 더 자세히 살펴 보는 동안 잠시 동안 주요 mea culpa로 끝날 것이라고 생각했습니다. 결국 Web Forms 아키텍처 및 테스트 가능성에 더 많은 에너지를 소비해야한다고 생각하지만 MVC는 실제로 그 요구에 응답하지 않습니다. 따라서 초기 답변에 대한 지적 비판을 제공 한 사람들에게 진심으로 “감사합니다”.

이것을 종교적 전투 로 보았고 공감대 홍수를 끊임없이 설계 한 사람들에 대해, 나는 왜 당신이 귀찮게하는지 이해하지 못합니다 (여러 번에 서로 몇 초 안에 20 개 이상의 공표가 확실히 정상이 아닙니다). 이 답변을 읽고 점수가 다른 답변보다 훨씬 낮다는 점을 감안할 때 내 답변에 대해 정말로 “잘못된”것이 있는지 궁금한 경우, 일반적인 의미보다 동의하지 않는 소수의 사람들에 대해 더 많은 것을 말하십시오. 커뮤니티 (전체적으로 100 번 이상 공표되었습니다).

사실 많은 개발자가 MVC를 신경 쓰지 않으며 실제로 블로그가 나타내는 것처럼 MS 내에서도 소수의 견해가 아닙니다.

답변

<% if (Model.PreviousPost || Model.NextPost) { %>
    <div class="pager">
        <% if (Model.PreviousPost) { %>
            <span><% Html.ActionLink("<< " + Model.PreviousPost.Subject, "view")); %></span>
        <% } if (Model.NextPost) { %>
            <span><% Html.ActionLink(Model.NextPost.Subject + " >>", "view")); %></span>
        <% } %>
    </div>
<% } %>

<% Html.RenderPartial("Pager", Model.PagerData) %>

 <%
    var PreviousPost = ViewData.Model.PreviousPost;
    var NextPost = ViewData.Model.NextPost;

    // Display the "Next and Previous" links
    if (PreviousPost != null || NextPost != null)
    {
  %>

 <div>

        <%= PreviousPost == null
                ? string.Empty
                : Html.ActionLinkSpan("<< " + PreviousPost.Subject,
                                "view",
                                new { id = PreviousPost.Id },
                                new { style = "float: left;" } ) %>
          <%= NextPost == null
                ? string.Empty
                : Html.ActionLinkSpan( NextPost.Subject + " >>",
                                   "view",
                                    new { id = NextPost.Id },
                                    new { style = "float: right;" } ) %>

  <div style="clear: both;" />
  </div>

  <% } %>