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


141

CTP 이후로 ASP.NET MVC를 다루어 왔으며 많은 일을 좋아하지만 얻지 못하는 것이 있습니다.

예를 들어, 나는 beta1을 다운로드했고 작은 개인 사이트 / 이력서 / 블로그를 함께 가지고 있습니다. ViewSinglePost 뷰의 스 니펫은 다음과 같습니다.

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

            if (ViewData.Model.PreviousPost != null)
            {
                %> <span style="float: left;"> <%
                    Response.Write(Html.ActionLink("<< " + ViewData.Model.PreviousPost.Subject, "view", new { id = ViewData.Model.PreviousPost.Id }));
                %> </span> <%
            }

            if (ViewData.Model.NextPost != null)
            {
                %> <span style="float: right;"> <%
                    Response.Write(Html.ActionLink(ViewData.Model.NextPost.Subject + " >>", "view", new { id = ViewData.Model.NextPost.Id }));
                %> </span> <%
            }
            %>
                   <div style="clear: both;" />
               </div> <%
        }
    %>

역겨운! (또한 HTML에는 임시 자리 표시 자 HTML이 있으므로 기능이 작동하면 실제 디자인을 만들 것입니다) .

내가 뭔가 잘못하고 있습니까? 나는 고전적인 ASP에서 많은 어두운 날을 보냈기 때문에이 태그 수프는 그것을 강력하게 상기시킵니다.

모든 사람이 당신이 더 깔끔한 HTML을 할 수있는 방법을 설교합니다. 뭔지 맞춰봐? 모든 사람의 1 %가 출력 된 HTML을 봅니다. 나에게, 유지하기 쉬운 코드가있는 한 Webforms가 렌더링 된 HTML에서 들여 쓰기를 엉망으로 만들지 않아도됩니다.

그래서, 다이 하드 webforms 사람, 나를 변환하기 위해 왜 멋지게 형성된 ASPX 페이지를 포기해야합니까?

편집 : "temp Html / css"줄을 굵게 표시하여 사람들이 그것에 대해 설명합니다.


3
못생긴 마크 업인 남자!
Steven A. Lowe

39
HTML에 CSS 마크 업을 포함 하시겠습니까?
Todd Smith

12
당신의 서식이 짜증납니다. 이것은 MVC 고유의 문제가 아니며 나쁜 HTML 프로그래머의 신호입니다. 관찰자 패턴에서 너무 많은 시간을 보냈다고 생각합니다. 끌어다 놓기, 클릭 이상의 작업이 필요합니다.
Chris

7
MVC를 신경 쓰지 마십시오. Winforms를 "쉬운 유지 관리"라고 부르는 것은 어리 석습니다. 출력을 어느 정도 제어 할 필요가없는 한 유지 관리가 쉽습니다. 즉, 사용자가 MS 인증 웹 브라우저 만 사용하는 한 제대로 작동합니다.
jalf

2
내가 뭔가 잘못하고 있습니까? - 예. 그러나 그것은 당신의 잘못이 아닙니다. 멋진 HTML을 작성한 다음 모델의 출력을 HTML에 추가해야합니다. Response.Write가 필요하지 않습니다! MVC 프레임 워크의 기본 개념은 .aspx보다 훨씬 깔끔하게 만드는 반면, 예제는 클래식 ASP처럼 보입니다.
Fenton

답변:


152

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 내에서도 소수의 견해가 아닙니다.


32
-1, 원래의 질문은 좋습니다-왜 좋은지 이해하지 못하고 더 많은 정보를 요구하는 것은 훌륭합니다. 그러나이 답변은 매우 이상합니다. 기본적으로 "모두 이해하지 못합니다"라고 말하지만 이야기에 포함시킵니다.
orip

49
ASP.NET MVC에 대한 비판이 추상화와 오버 헤드를 추가한다는 점이 흥미 롭습니다. 따라서 더 복잡합니다. 정확히 반대입니다. Webforms는 추상화 계층을 추가하고 MVC는 훨씬 더 직설적이고 저수준이므로 현재 수행중인 작업에서 숨길 수 없습니다.
Trevor de Koekkoek

75
포스터가 대답 할 때 MVC 패턴에 대해 전혀 알지 못했을 때 왜 이것이 "답변"으로 표시됩니까?
ScottKoon

12
ScottKoon-동의 한 이유는 확실하지 않습니다. 그가 한 모든 것이 OP에 동의 한 것 같습니다. -1
Jared

11
웹 패러다임에 더 잘 맞는 WebForms의 특성화에 문제가 있습니다. WebForms는 기본적으로 웹에 오버레이 된 이벤트 중심 WinForms 모델입니다. 이와 같이 프레임 워크와 개발자가 천국을 금지하는 경우 비 MS 클라이언트 도구를 사용하여 무언가를 시도하는 경우 웹을 통한 이벤트 처리를 수행하는 척하기 위해 많은 노력을 기울여야합니다. . MVC는 RESTful 인터페이스에 매우 적합하며 REST는 웹 프로토콜을 의도 한 용도로 사용하려고 시도합니다. MS는 웹폼이 웹에 가장 적합하지 않기 때문에 WebForms를 디자인했습니다.
tvanfosson

117

MVC를 사용하면 출력을보다 강력하게 제어 할 수 있으며,이 컨트롤을 사용하면 제대로 디자인되지 않은 HTML, 태그 수프 등을 작성할 위험이 커집니다.

그러나 동시에 이전에는 없었던 몇 가지 새로운 옵션이 있습니다 ...

  1. 페이지 및 페이지 내의 요소를보다 세밀하게 제어
  2. ViewState와 같이 출력에서 ​​"정크"가 적거나 요소의 ID가 너무 길다 (오해하지 말고 ViewState를 좋아한다)
  3. Javascript를 사용하여 클라이언트 측 프로그래밍을 수행하는 기능이 향상되었습니다 (Web 2.0 Applications 누구입니까?)
  4. MVC뿐만 아니라 JsonResult는 매끄 럽습니다 ...

이제 WebForms로 이러한 작업을 수행 할 수는 없지만 MVC를 사용하면 더 쉽게 할 수 있습니다.

서버 컨트롤 등을 활용할 수 있기 때문에 웹 응용 프로그램을 빠르게 만들어야하는 경우에도 여전히 WebForms를 사용합니다. WebForms는 입력 태그 및 제출 버튼의 모든 세부 정보를 숨 깁니다.

부주의 한 경우 WebForms와 MVC 모두 절대 가비지가 가능합니다. 항상 그렇듯이 신중한 계획과 신중한 디자인은 MVC이든 WebForms이든 관계없이 양질의 애플리케이션이 될 것입니다.

[최신 정보]

위로가 될 경우 MVC는 Microsoft의 새로운 기술입니다. WebForms가 남아있을뿐만 아니라 계속 개발 될 것이라는 많은 게시물이 있습니다 ...

http://haacked.com

http://www.misfitgeek.com

http://rachelappel.com

... 등등...

MVC가 취항하는 노선에 관심이있는 분들을 위해 "남자들"에게 피드백을 제공 할 것을 제안합니다. 지금까지 듣고있는 것 같습니다!


10
포인트 1과 2가 핵심이라고 생각합니다. 추상화로서의 웹폼은 실제로 진행되고있는 것 위에 잘 매핑되는 추상화가 아니기 때문에 IMHO는 실제로 "작동"하지 않습니다. ASP.NET MVC는 webforms보다 MVC를 사용하여 제한된 경험을 제공하는 것보다 더 적합한 추상화라고 생각합니다.
Daniel Auger

3
그리고 많은 사람들이 MVC 나 Webform을 건드리지 않고 ASP.Net을 사용합니다. webforms 모델을 완전히 피하고 페이지 뒤의 코드에서 모든 것을 수행하는 많은 .Net 응용 프로그램을 보았습니다. 그리고 솔직히, 나는 그것이 더 잘 작동한다고 생각합니다.
Kibbee

업데이트 HBoss에 감사드립니다! MS가 WebForms를 7 년 동안 사용한 후에 WebForms를 포기하는 것을 싫어합니다.
Mark Brittingham

1
Daniel-Webforms는 웹 모델에 제대로 매핑되지 않기 때문에 "작동하지 않습니다"라고 말합니다. 나는 정식으로 동의하지 않습니다 : http는 문서 를 검색하기위한 모델로 시작되었습니다 . Webforms 아키텍처는 단순히 문서의 개념을 확장하여 문서가 동적이되도록합니다. 이것은 나를 위해 작동합니다 ...
Mark Brittingham

3
@mdbritt. 높은 수준의 추상화 (문서 검색)에서 사실이므로 귀하의 의견을 존중합니다. 그러나 나를 위해 psuedo statefulness 및 postback 모델은 특히 매우 역동적 인 시나리오에서 분해되기 시작합니다. 간단한 작업에는 효과적이지만 빨리 풀립니다.
Daniel Auger

76

ASP.NET MVC에 대한 대부분의 반대 의견은 아키텍처에서 가장 "선택적인"모듈 형 비트 중 하나 인 뷰를 중심으로 보입니다. NVelocity , NHaml , Spark , XSLT 및 기타 뷰 엔진을 쉽게 교체 할 수 있습니다 (모든 릴리즈에서 더 쉬워지고 있습니다). 많은 것들이 프리젠 테이션 로직과 포맷팅을위한 간결한 구문을 가지고 있으며, 방출 된 HTML을 여전히 완벽하게 제어합니다.

그 외에도 거의 모든 비판이 기본보기에서 <% %> 태그로 표시되고 이것이 얼마나 "추악한"지에 대한 것 같습니다. 이러한 의견은 종종 WebForms 접근 방식에 익숙해 져 대부분의 기존 ASP 추악함을 코드 숨김 파일로 옮깁니다.

코드 숨김을 "잘못"하지 않아도 리피터의 OnItemDataBound와 같은 항목이 있습니다.이 항목은 "태그 수프"와는 다른 방식 으로 미학적으로보기 흉한 방법입니다. foreach 루프는 특히 루프 이외의 ASP.NET 기술에서 MVC를 사용하는 경우 해당 루프의 출력에 변수를 포함하더라도 훨씬 쉽게 읽을 수 있습니다. foreach 루프를 이해하는 데 중계기에서 해당 필드를 수정하는 방법은 OnItemDataBound (및 변경해야하는 올바른 요소인지 확인하는 쥐의 둥지)를 엉망으로 만드는 것임을 이해하는 것보다 Google-fu가 훨씬 적습니다.

ASP 태그 수프 중심의 "스파게티"의 가장 큰 문제는 HTML 사이에 데이터베이스 연결과 같은 것들을 넣는 것에 관한 것이 었습니다.

<% %>를 사용하여 그렇게 된 것은 인과 관계가 아닌 클래식 ASP의 스파게티 특성과의 상관 관계 일뿐입니다. 뷰 로직을 HTML / CSS / Javascript로 유지하고 프리젠 테이션 을 수행하는 데 필요한 최소한의 로직을 유지 하면 나머지는 구문입니다.

특정 기능을 WebForms와 비교할 때 MVC 솔루션이 실제로 훨씬 단순하지 않도록 디자이너가 생성 한 모든 C # 및 코드 숨김 C #을 .aspx 코드와 함께 포함해야합니다. .

반복 가능한 표현 논리 비트에 대한 부분 뷰의 적절한 사용과 결합하면 실제로 훌륭하고 우아 할 수 있습니다.

개인적으로, 나는 초기 학습 내용의 대부분이 테스트 중심, 제어 역전 등 거의 독점적 으로이 목적에 더 초점을 맞추기를 바랍니다. "태그 수프"에 반대합니다.

어쨌든, 이것은 아직 베타 버전 인 플랫폼입니다. 그럼에도 불구하고 대부분의 Microsoft- 베타 기술보다 더 많은 배포 및 Microsoft 이외의 개발자가 실제 물건을 구축하는 방법이 늘어나고 있습니다. 따라서 버즈는 주변의 인프라 (문서, 안내 패턴 등)보다 더 멀리있는 것처럼 보이게하는 경향이 있습니다. 이 시점에서 진정으로 사용할 수 있으면 그 효과가 증폭됩니다.


1
다른 뷰 엔진에서 쉽게 교체 할 수 있다는 것을 몰랐습니다. 자세한 정보를 제공 할 수 있습니까?
RedFilter

편리한 링크는 없지만 Phil Haack은 몇 주 전에 자신의 사이트에서 기사를 나란히 실행할 수있는 방법을 보여주는 기사를 작성했습니다.
J Wynia

1
아멘! Findcontrol을 사용하는 것을 싫어합니다. 너무 싫어
Adam Lassek

3
훌륭하고 둥근 포스트.
Owen

59
<% 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>
<% } %>

포함 된 CSS를 포함하지 않고이 작업을 수행하는 방법을 묻는 다른 게시물을 만들 수 있습니다.

참고 : ViewData.Model은 다음 릴리스에서 모델이됩니다.

그리고 사용자 컨트롤의 도움으로 이것은

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

여기서 PagerData는 작업 처리기에서 익명 생성자를 통해 초기화됩니다.

편집 :이 문제에 대한 WebForm 구현의 모양이 궁금합니다.


4
좋은 소식입니다. 코드를 더 깨끗하게 만드는 RenderPartial을 통한 재사용과 같은 일부 기술에서는 OP가 누락되었습니다. OP의 수비에서 그는 자신이 뭔가 잘못하고 있다고 생각한다고 암시했다.
Daniel Auger

25

사람들이 코드에 대한 관심을 멈추는 시점이 확실하지 않습니다.

HTML은 작업의 가장 공개적인 표시이며, 메모장, 메모장 ++ 및 기타 일반 텍스트 편집기를 사용하여 많은 웹 사이트를 구축하는 개발자가 많이 있습니다.

MVC는 웹 양식에서 제어권을 다시 가져오고 상태 비 저장 환경에서 작업하며 일반적으로이 패턴을 구현할 때 발생하는 추가 작업없이 Model View Controller 디자인 패턴을 구현하는 것입니다.

제어, 깔끔한 코드 및 MVC 디자인 패턴을 사용하려는 경우 이는 마크 업 작업이 마음에 들지 않으면 마크 업의 기형에 신경 쓰지 말고 ASP.Net Web Forms를 사용하십시오.

어느 쪽이든 마음에 들지 않으면 마크 업에서 거의 많은 작업을 수행하게 될 것입니다.

편집 나는 또한 Web Forms와 MVC가 자신의 자리를 가지고 있다고 진술해야하며, 나는 하나가 다른 것보다 낫다는 것을 말하지 않았고 각 MVC는 마크 업에 대한 제어력을 회복하는 힘을 가지고 있다고 주장했다.


6
출력 마크 업 (포인트)에 신경 쓰지 않고 유지 관리 가능한 코드에 관심이 있습니다. Webforms의 트레이드 오프는 IMHO의 가치가 없습니다.
FlySwat

1
자세히 설명하기 위해 Webforms에서 좋은 마크 업에 문제가 없었습니다.
FlySwat

2
2MB의 Viewstate를 볼 때 실제 요소의 이름이 잘못되어 웹 양식에서 컨트롤을 찾으려면 많은 컨트롤 검색을 수행해야합니다.이 빛을 환영합니다. 나는 항상 내 코드에 대해 항문 적이었고 누구나 소스를 볼 수 있으며 OCD가 있고 집을 깨끗하게하고 싶습니다.
Tom Anderson

5
당신이하고있는 일을 모른다면 2MB의 viewstate 만 얻습니다.
FlySwat

3
당신이하는 일을 모르고 코드를 함께 던질 때 태그 수프를 얻는다.
Hugoware

15

네가 빠진 것 같아 먼저 Response가 필요 없으며, <%= %>태그를 사용할 수 있습니다 . 둘째, 일반적인 작업을 수행하기 위해 자체 HtmlHelper 확장을 작성할 수 있습니다. 셋째, 약간의 서식 지정이 많은 도움이됩니다. 넷째,이 모든 것이 여러 다른 뷰간에 공유되도록 사용자 정의 컨트롤에 붙어있을 수 있으므로 기본 뷰의 전체 마크 업이 더 깨끗합니다.

마크 업이 원하는만큼 깔끔하지는 않지만 임시 변수를 사용하면 상당히 정리할 수 있습니다.

이제는 그렇게 나쁘지 않으며 SO 용으로 포맷하지 않아도 더 좋습니다.

 <%
    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>

  <% } %>

2
Webforms에서 <asp : hyperlink>의 가시성을 설정할 수 있다고 생각하면 여전히 그렇게 이상하지 않습니까?
FlySwat

2
아니요, 웹 양식조차 그렇게 간단하지 않기 때문입니다. 동적이기 때문에 코드 숨김에서 하이퍼 링크에 대한 일부 속성을 설정해야 할 수도 있습니다. DIV / 스팬 코드는 여전히 필요하지만 메소드로 롤링 할 수는 없습니다. 그리고 그 중 어느 것도 테스트 할 수 없습니다.
tvanfosson

3
데이터 바인딩 컨트롤을 처리하고 클라이언트 측에서 원하는 작업을 수행하는 데 필요한 고통과 테스트 코드의 양을 2 배 이상 늘리는 데 도움이되는 충분한 웹 양식을 만들었습니다. 나는 이것이 전혀 이상하게 보이지 않을 정도로 Rails에서 충분히 해냈습니다.
tvanfosson

1
NavigateUrl과 Visibility를 설정해야합니다. page_load 이벤트에서 2 줄이됩니다.
FlySwat

2
나는 당신이 레일에서 이것을하고 있다고 생각합니다. 내가 마지막으로 한 것은 고전적인 ASP였으며, 여기에는 미워해야 할 다른 많은 이유가 있습니다. 아마도 <% %> 태그의 초기 개그 리플렉션을 극복해야 할 것입니다.
FlySwat

14

MVC의 가장 큰 장점은 오랫동안 사용되어 온 개념적 프레임 워크이며 가로 및 세로로 확장되는 웹 응용 프로그램과 워크 스테이션 응용 프로그램을 모두 생산할 수있는 생산적이고 강력한 방법으로 입증되었습니다. 알토와 스몰 토크로 바로 돌아갑니다. 마이크로 소프트는 파티에 늦었다. ASP.NET MVC에서 우리가 지금 가지고있는 것은 정말 원시적입니다. 왜냐하면 따라야 할 일이 너무 많기 때문입니다. 그러나 젠장, 그들은 새 릴리스를 빠르고 격렬하게 쏟아 부었습니다.

Ruby on Rails의 가장 큰 장점은 무엇입니까? Rails는 MVC입니다. 입소문으로 프로그래머가 생산성을 높일 수있는 방법이 되었기 때문에 개발자들은 전환을 해왔습니다.

대단한 일입니다. MVC와 jQuery의 암시 적 보증은 플랫폼 중립적이라는 것이 중요하다는 점을 Microsoft가 받아들이는 요령입니다. 그리고 중립적 인 점은 Web Forms와 달리 Microsoft는 개념적으로 귀하를 잠글 수 없다는 것입니다. 코드 자체가 아닌 이식 가능한 MVC 개념이기 때문에 모든 C # 코드를 가져 와서 다른 언어 (예 : PHP 또는 java-이름 지정)로 완전히 다시 구현할 수 있습니다. 또한 코드를 거의 변경하지 않고 디자인을 변경하지 않고도 디자인을 가져 와서 워크 스테이션 앱으로 구현할 수 있다는 것이 얼마나 큰지 생각해보십시오. Web Forms를 사용해보십시오.

Microsoft는 Web Forms가 다음 VB6이되지 않기로 결정했습니다.


1
여기에 추가 : 기본 WebForms 및 RoR의 HAML 포트 (특히 꺾쇠 괄호, 특히 퍼센트 기호를 포함하는 경우 금지)를 포함하여 MVC에 연결하는 여러 가지 뷰 엔진이 있습니다.
yfeldblum

흥미로운 점은 ... 좋은 점
Hugoware

HAML FTW, 특히 MVC에 대한 귀하의 반대 의견이 <% %> 인 경우
Peter Recore


9

웹 양식에 비해 ASP.NET MVC 프레임 워크의 두 가지 주요 장점은 다음과 같습니다.

  1. 테스트 가능성 -웹 양식의 UI 및 이벤트는 테스트가 불가능합니다. ASP.NET MVC를 사용하면 단위 테스트 컨트롤러 작업과 렌더링 뷰가 쉽습니다. 여기에는 초기 개발 비용이 들지만, 연구 결과에 따르면 앱을 리팩터링하고 유지 관리해야 할 때 장기적으로 이익을 얻습니다.
  2. 렌더링 된 HTML을보다 효율적으로 제어 -렌더링 된 HTML을 아무도 보지 않기 때문에 신경 쓰지 않아도됩니다. 그것이 HTML 형식을 올바르게 설정 한 유일한 이유라면 유효한 불만입니다. SEO, CSS 및 자바 스크립트에서 id 선택기를 더 자주 사용하는 기능, viewstate 부족으로 인한 페이지 풋 프린트 감소 및 엄청나게 긴 id (ctl00_etcetcetc)를 포함하여 올바른 형식의 HTML을 원하는 여러 가지 이유가 있습니다.

이제 이러한 이유 때문에 ASP.NET MVC가 웹 양식보다 흑백 형식으로 나아지는 것은 아닙니다. ASP.NET MVC는 웹 양식과 마찬가지로 장단점이 있습니다. 그러나 ASP.NET MVC에 대한 대부분의 불만은 프레임 워크의 실제 결함보다는 사용 방법에 대한 이해 부족에서 비롯된 것 같습니다. 코드가 적절하지 않거나 올바르게 보이지 않는 이유는 몇 년 동안 웹 양식 경험이 있고 1-2 개월의 ASP.NET MVC 경험 만 있기 때문일 수 있습니다.

여기서 문제는 ASP.NET MVC가 흔들 리거나 빨라지는 것이 아니라 새롭고 올바르게 사용하는 방법에 대한 동의가 거의 없다는 것입니다. ASP.NET MVC는 앱에서 발생하는 상황을보다 세밀하게 제어합니다. 접근 방식에 따라 특정 작업을 더 쉽고 어렵게 만들 수 있습니다.


8

안녕하세요, MVC로 전환하는 데 어려움을 겪고 있습니다. 나는 고전적인 ASP의 팬이 아니며 MVC 렌더링은 그 당시 많은 것을 상기시켜줍니다. 그러나 MVC를 많이 사용할수록 더 많이 성장합니다. 나는 webforms 사람 (많은 사람들처럼)이며 지난 몇 년 동안 데이터 그리드 등을 다루는 데 익숙해졌습니다. HTML 헬퍼 클래스가 답입니다.

최근에 나는 MVC에서 "그리드"에 페이징을 추가하는 가장 좋은 방법을 찾으려고 2 일을 보냈다. 이제 webforms를 사용하면 즉시 채울 수 있습니다. 그러나 나는 이것을 말할 것입니다 ... 일단 MVC 용으로 작성된 페이징 도우미 클래스가 있으면 구현하기가 매우 간단 해졌습니다. 나에게 웹폼보다 훨씬 쉽다.

즉, 일관된 HTML 헬퍼 세트가있을 때 MVC가 훨씬 개발자 친화적이라고 생각합니다. 가까운 장래에 웹에 수많은 HTML 도우미 클래스가 나타날 것입니다.


내가 아직 그 문제를 어떻게 해결할지 모르겠 기 때문에 페이징 구현을보고 싶습니다 :)
dtc

여기 내가 페이징 도우미를 얻는 곳입니다. 현재 샘플 프로젝트를 다운로드 할 수 있습니다 blogs.taiga.nl/martijn/archive/2008/08/27/...
파파 부르고뉴

다른 것과 마찬가지로 학습 곡선이 있습니다. 특정 지역의 작업이 얼마나 더 나은지에 대해 놀랄 것입니다. 서버 컨트롤 및 viewstate가 같은 사치품의 일부가되어 - 그래도 난 거짓말을하지 않습니다 확실히 놓쳤다. <asp : TextB ...를 입력 한 다음 깨달았습니다 ... 으악 !!
Hugoware

솔직한 질문이 있습니다. HTML "Helper"클래스가 필요한 경우 실제로 MVC 모델을 위반하지 않았습니까? 당신은 그것이 판매되는 단순성과 우아함을 떠나지 않습니까? 내가 틀렸다면 (그리고 있을지도 모른다!) 이유를 말해주십시오.
Mark Brittingham

1
MVC로 "전환"해야한다고 생각하지 않습니다. 프로젝트에 따라 여전히 WebForms를 사용합니다.
Hugoware

8

내가 처음 webforms을봤을 때 말한 것이기 때문에 재미있다.


정말 그렇습니다 . WebForms는 우리에게 가져 왔던 시대의 상황을 알지 못하고 거의 이해가되지 않습니다. 웹을 포용하지 않고 숨기려고 시도하며 추상화가 매우 열악합니다.
Jason Bunting

6

아직 asp.net MVC를 얻지 못했음을 인정합니다. 내가하고있는 사이드 프로젝트에서 사용하려고하지만 꽤 느리게 진행됩니다.

웹 양식에서 너무 쉽게 할 수없는 일 외에도 태그 수프를 발견했습니다. 그것은 실제로 그 관점에서 한 단계 뒤로 물러서는 것 같습니다. 나는 배우면서 나아질 것으로 기대합니다.

지금까지 MVC를 사용하는 가장 큰 이유는 HTML을 완전히 제어하는 ​​것입니다. 또한 asp.net MVC가 웹 양식보다 더 많은 페이지를 제공 할 수 있으며 이와 관련이있을 수 있으며 개별 페이지 크기는 평균 웹 양식 페이지보다 작습니다.

HTML이 주요 브라우저에서 작동하는 한 HTML의 모양은 중요하지 않지만 페이지로드 속도 및 차지하는 대역폭은 중요합니다.


6

나는 그것이 못생긴 마크 업이라는 것에 완전히 동의하지만 ASP.NET MVC를 전체적으로 작성하기 위해 못생긴 뷰 구문을 사용하는 것은 불공평하다고 생각합니다. 뷰 구문은 Microsoft의 관심을 가장 적게 받았으며 곧 그것에 대해 무언가를 기대하고 있습니다.

다른 답변은 MVC의 장점을 전체적으로 논의 했으므로 뷰 구문에 중점을 둘 것입니다.

HTML을 생성하는 Html.ActionLink 및 기타 메소드를 사용하도록 권장하는 것은 잘못된 방향으로의 단계입니다. 이것은 서버 제어의 부족이며 존재하지 않는 문제를 해결하고 있습니다. 코드에서 태그를 생성하려는 경우 HTML을 전혀 사용하지 않는 이유는 무엇입니까? DOM 또는 다른 모델을 사용하여 컨트롤러에 컨텐츠를 구축 할 수 있습니다. 좋아, 그거 안 좋은데? 그렇습니다. 우려가 분리 되었기 때문에 우리는 견해를 가지고 있습니다.

올바른 방향은 뷰 구문을 HTML과 최대한 비슷하게 만드는 것입니다. 잘 설계된 MVC는 컨텐츠에서 코드를 분리 할뿐만 아니라 뷰에 대한 레이아웃 전문가 (ASP.NET을 모르더라도)에 대해 전문 지식을 가진 사람들이 작업을 능률화 할 수 있도록해야합니다. 나중에 개발자로 들어가서 모형을 실제로 동적으로 만들 수 있습니다. 뷰 구문이 HTML과 매우 유사 해 레이아웃 사람들이 DreamWeaver 또는 현재 널리 사용되는 레이아웃 도구를 사용할 수있는 경우에만이 작업을 수행 할 수 있습니다. 한 번에 수십 개의 사이트를 구축하고있을 수 있으며 생산 효율성을 위해 이러한 방식으로 확장해야합니다. "언어"보기가 어떻게 작동하는지 볼 수있는 예를 들어 보겠습니다.

<span mvc:if="ViewData.Model.ShowPrevious" style="float: left;">
    <a mvc:inner="ViewData.Model.PreviousPost.Subject" href="view/{ViewData.Model.PreviousPost.Id}">sample previous subject</a>
</span> 
<span mvc:if="ViewData.Model.ShowNext" style="float: left;">
    <a mvc:inner="ViewData.Model.NextPost.Subject" href="view/{ViewData.Model.NextPost.Id}">sample next subject</a>
</span> 
<div mvc:if="ViewData.Model.ShowNextOrPrevious" style="clear: both;" />

여기에는 몇 가지 장점이 있습니다.

  • 더 좋아 보인다
  • 더 간결한
  • HTML과 <% %> 태그 사이에 펑키 한 컨텍스트 전환이 없음
  • 자명 한 키워드를 쉽게 이해할 수 있습니다 (비 프로그래머도이를 수행 할 수 있음-병렬화에 적합)
  • 가능한 많은 로직을 컨트롤러 (또는 모델)로 다시 이동
  • HTML을 생성하지 않음-다시 말하면 Html을 엉망으로 만들지 않고도 누군가가 스타일을 지정할 수있는 곳을 쉽게 알 수 있습니다. 행동 양식
  • 코드에는 브라우저에 뷰를 일반 HTML로로드 할 때 렌더링되는 샘플 텍스트가 포함되어 있습니다.

그렇다면이 구문은 정확히 무엇을합니까?

mvc : inner = ""-따옴표 안에있는 내용이 평가되고 태그의 내부 HTML이 결과 문자열로 바뀝니다. (샘플 텍스트가 바뀝니다)

mvc : outer = ""-따옴표 안에있는 내용이 평가되고 태그의 외부 HTML이 결과 문자열로 바뀝니다. (또 샘플 텍스트가 바뀝니다.)

{}-<% = %>와 유사한 속성 안에 출력을 삽입하는 데 사용됩니다

mvc : if = ""-qoutes는 평가할 부울 표현식입니다. if의 끝은 HTML 태그가 닫히는 곳입니다.

mvc : 다른

mcv : elseif = ""-...

mvc : foreach


1
자신의 뷰 엔진으로 묘사하는 것을 정확하게 쉽게 구현하고 WebForms 솔루션을 완전히 버릴 수 있습니다.
J Wynia

1
사용 가능한 다른 뷰 엔진이 있으며 cf 스타일 마크 업이 잘 작동한다고 생각합니다. 여기에 표시됩니다.
트래커 1

정보 주셔서 감사합니다, 다른보기 엔진이 있다는 것을 알지 못했습니다.
RedFilter

Genshi는 비슷한 접근 방식을 가진 인기있는 파이썬 템플릿 엔진입니다. genshi.edgewall.org/wiki/…
orip

그러나 아무도 XSL을 좋아하지 않았으므로 어떻게 이것이 채택 될 것으로 기대하십니까?
BobbyShaftoe

4

이제 나는 여기서 만 말할 수 있습니다.

IMO, 당신이 열심히 일하는 사람이라면 전환은 당신을위한 것이 아닙니다. WebForms를 좋아한다면 필요한 것을 달성 할 수 있기 때문입니다. 그 목표도 마찬가지입니다.

Webforms는 개발자 로부터 HTML을 추상화하는 작업을 잘 수행합니다 . 이것이 목표라면 Web Forms를 고수하십시오. 데스크탑 개발을 오늘날처럼 만들어 낸 훌륭한 "클릭 앤 드래그"기능이 있습니다. 다양한 기능을 제공 할 수있는 많은 포함 된 컨트롤 (및 다양한 타사 컨트롤)이 있습니다. 데이터베이스에서 DataSource와 직접 연결된 "그리드"를 드래그 할 수 있습니다. 인라인 편집, 페이징 등이 내장되어 있습니다.

현재 ASP.NET MVC는 타사 컨트롤 측면에서 매우 제한적입니다. 다시 말하지만, 많은 기능이 연결되어있는 Rapid Application Development를 좋아한다면 변환을 시도해서는 안됩니다.

이 모든 것이 말하면 ASP.NET이 빛나는 곳입니다.-TDD. Nuff는 코드를 테스트 할 수 없다고 말했다.

  • 우려의 분리. 이것이 MVC 패턴의 중추입니다. Web Forms에서이 작업을 수행 할 수 있음을 충분히 알고 있습니다. 그러나 나는 부과 된 구조를 좋아한다. Web Forms에서는 디자인과 논리를 혼합하기가 너무 쉽습니다. ASP.NET MVC를 사용하면 팀의 다른 구성원이 응용 프로그램의 다른 섹션에서보다 쉽게 ​​작업 할 수 있습니다.

  • 다른 곳에서 왔습니다 : 제 배경은 CakePHP와 Ruby on Rails입니다. 따라서 내 편견이 어디에 있는지 분명합니다. 그것은 당신이 편한 것에 관한 것입니다.

  • 학습 곡선 : 마지막 지점에서 확장합니다. 다른 요소의 기능을 변경하려는 "템플릿"이라는 아이디어를 싫어했습니다. 파일 숨김 코드에서 많은 디자인이 이루어 졌다는 사실이 마음에 들지 않았습니다. 내가 이미 HTML과 CSS에 친숙 할 때 배워야 할 것이 하나 더 있습니다. 페이지의 "요소"에서 무언가를하고 싶다면, "div"또는 "span"을 고수하고 ID를 두드린 후 꺼냅니다. Web Forms에서이 작업을 수행하는 방법을 조사해야합니다.

  • 웹의 현재 상태 "디자인": jQuery와 같은 자바 스크립트 라이브러리가 점점 일반화되고 있습니다. Web Forms가 ID를 엉망으로 만드는 방식은 Visual Studio 외부에서 구현을 더욱 어렵게 만듭니다.

  • 더 많은 분리 (디자인) : 많은 디자인이 컨트롤에 연결되어 있기 때문에 외부 디자이너 (Web Forms 제외) 지식이 Web Forms 프로젝트에서 작동하기가 매우 어렵습니다. Web Forms는 모두 끝이되도록 만들어졌습니다.

다시 말하지만, 이러한 이유 중 다수는 Web Forms에 익숙하지 않기 때문입니다. Web Forms 프로젝트 (올바로 설계된 경우)는 ASP.NET MVC의 이점을 "가장 많이"가질 수 있습니다. 그러나 이것이 바로 경고입니다. "올바로 설계된 경우". 그리고 그것은 Web Forms에서 수행하는 방법을 모르는 것입니다.

Web Forms에서 훌륭한 작업을 수행하는 경우 효율적이며 효과가 있습니다.

기본적으로 장단점 목록을 사용하여 두 가지 모두에 대해 빠른 검토를 수행하고 (편견없는 소스를 찾아보십시오 [행운]) 목표에 맞는 것을 평가하고이를 바탕으로 선택하십시오.

결론은 저항을 최소화하고 목표를 달성하는 데 가장 도움이되는 경로를 선택하는 것입니다. Web Forms는 매우 성숙한 프레임 워크이며 앞으로 더 나아질 것입니다. ASP.NET MVC는 루비 온 레일즈와 CakePHP 개발자 (나 같은 : P)를 그리는 또 다른 대안입니다.


3

Java EE의 JSP는 처음 제안되었을 때 이와 같이 생겼습니다 – 추악한 스크립틀릿 코드.

그런 다음 태그 라이브러리를 제공하여 HTML 태그를 더 많이 만들었습니다. 문제는 누구나 태그 라이브러리를 작성할 수 있다는 것입니다. 사람들이 HTML을 생성하는 태그 라이브러리에 많은 논리 (및 스타일)를 포함 시켰기 때문에 일부 결과는 비참했습니다.

가장 좋은 해결책은 JSP 표준 태그 라이브러리 (JSTL)라고 생각합니다. HTML 표준 인 "표준"이며 사람들이 로직을 페이지에 넣지 못하게합니다.

추가 이점은 웹 디자이너와 개발자 간의 경계를 유지한다는 것입니다. 내가 보는 좋은 사이트는 미적 감각과 유용성을 위해 디자인 된 사람들이 디자인 한 것입니다. 그들은 페이지와 CSS를 배치하고 동적 데이터 비트를 추가하는 개발자에게 전달합니다. 이러한 선물이 부족한 개발자라고 말하면 개발자가 수프에서 견과류까지 웹 페이지를 작성하도록 요청할 때 중요한 것을 제공한다고 생각합니다. Flex와 Silverlight는 디자이너가 JavaScript와 AJAX를 잘 알지 못할 것이므로 같은 문제로 어려움을 겪을 것입니다.

.NET에 JSTL과 비슷한 경로가 있다면 조사해 보는 것이 좋습니다.


+1-더 줄 수 있다면. 네 ... 자바는이 길에서 오래 전에 내려 왔습니다. 이상한 부분은 Java가 JSF 및 Tapestry와 같이 구성 요소를 강화하는 일부 MVC 스타일 프레임 워크도 보았습니다. MVC는 웹 애플리케이션 IMHO를위한 유일한 상식 아키텍처에 관한 것입니다. 나는 뼈대가있는 쇠고기가 그것을 이해하지 못하게하지 않을 것입니다. 프레임 워크가 발전 할 것입니다.
cwash

3

이 샘플이 ASP .NET MVC 3 이후 기본값 인 반짝이는 새로운 Razor 뷰 엔진 과 어떻게 보이는지를 공유한다고 생각했습니다 .

@{ 
    var prevPost = ViewData.Model.PreviousPost;
    var nextPost = ViewData.Model.NextPost;
}

@if (prevPost != null || nextPost != null) {
    <div>
        @if (prevPost != null) {
            <span style="float: left;">
                @Html.ActionLink("<< " + prevPost.Subject, "view", new { id = prevPost.Id })
            </span>
        }
        @if (nextPost != null) {
            <span style="float: left;">
                @Html.ActionLink(nextPost.Subject + " >>", "view", new { id = nextPost.Id })
            </span>
        }
        <div style="clear: both;" />
    </div>
}

그것에 문제가 있습니까?
또한 실제로 CSS 스타일을 인라인해서는 안됩니다. 왜 두 곳이 아닌 세 곳에서 무효를 확인합니까? 여분의 div상처는 거의 없습니다. 이것이 내가하는 방법입니다.

<div>
    @if (prevPost != null) {
        @Html.ActionLink("<< " + prevPost.Subject, "view",
            new { id = prevPost.Id, @class = "prev-link" })
    }
    @if (nextPost != null) {
        @Html.ActionLink(nextPost.Subject + " >>", "view",
            new { id = nextPost.Id, @class = "next-link" })
    }
    <div class="clear" />
</div>

2

ASP.NET MVC 프로젝트와 직접 대화 할 수는 없지만 일반적으로 MVC 프레임 워크는 응용 프로그램 개발 을 지배하게 되었습니다.

  1. 데이터베이스 운영, "비즈니스 로직"및 프레젠테이션을 공식적으로 분리합니다.

  2. 개발자는 HTML / CSS / 자바 스크립트를 여러 브라우저 및 해당 브라우저의 향후 버전 에서 작동하도록 조정할 수있는 충분한 유연성을 제공 합니다.

중요한 것은이 마지막 비트입니다. Webforms 및 이와 유사한 기술을 사용하면 공급 업체를 통해 HTML / CSS / Javascript를 작성하게됩니다. 강력한 기능이지만 현재 버전의 Webforms가 차세대 웹 브라우저에서 작동한다는 보장은 없습니다.

그것이보기의 힘입니다. 애플리케이션의 HTML을 완전히 제어 할 수 있습니다. 단점은 뷰의 논리를 최소한으로 유지하고 템플릿 코드를 가능한 한 간단하게 유지하도록 충분히 훈련 받아야한다는 것입니다.

이것이 바로 트레이드 오프입니다. Webforms가 작동하지만 MVC가 작동하지 않는 경우 Webforms를 계속 사용하십시오.


1
"넌 HTML / CSS / 자바 스크립트를 작성하기 위해 공급 업체에 의존하고있다" 모든 사람이 미리 작성된 컨트롤을 사용합니까? 우리는 결코 없습니다.
FlySwat

1
포인트 1도 넌센스입니다. 내가 설계 한 모든 앱은 뷰에 대한 바인딩 로직 뒤에있는 코드만으로 강력하게 분리되었습니다. 코드 숨김의 이벤트 핸들러는 단순히 비즈니스 계층에서 적절한 메소드를 호출했습니다.
FlySwat

1
내가 말했듯이 Webforms가 당신을 위해 일하고 있고 상점에서 자체 컨트롤을 개발할 시간이 있다면 계속하십시오.
Alan Storm

1
@FlySwat-DropDownList 또는 DataGrid를 사용한 적이 없습니까?
Simon_Weaver

2

그것에 대한 나의 좌절의 대부분은 단지 "적절하게"일을하는 방법을 모른다. 미리보기로 출시 된 이후로 우리 모두는 사물을 볼 시간이 약간 있었지만 상당히 바뀌 었습니다. 처음에는 정말 좌절했지만 프레임 워크는 매우 복잡한 UI (읽기 : Javascript)를 매우 빠르게 만들 수있을 정도로 보입니다. 이전에 Webforms를 사용 하여이 작업을 수행 할 수 있음을 이해하지만 모든 것을 올바르게 렌더링하려고 시도하는 것은 엉덩이에 큰 고통이었습니다. 여러 번 나는 정확한 출력을 제어하기 위해 리피터를 사용하게되었고 결국 당신이 가지고있는 많은 스파게티 엉망으로 끝날 것입니다.

같은 혼란을 피하기 위해 도메인, 서비스 계층 및 dto를 조합하여 뷰로 전송했습니다. 뷰 엔진 인 spark와 함께 사용하면 정말 좋습니다. 설정하는 데 약간의 시간이 걸리지 만 일단 응용 프로그램이 복잡해지면 시각적으로 크게 향상되었지만 코드를 현명하게 작성하는 것은 간단합니다.

나는 아마 이것처럼 정확하게하지 않을 것이지만 여기에 당신의 예가 있습니다 :

<if condition="myDtp.ShowPager">
  <div>
    <first />
    <last />
    <div style="clear: both;" />
  </div>
</if>

그것은 유지 보수가 쉽고 테스트 가능하며 코드 스프에서 맛있습니다.

테이크 아웃은 깨끗한 코드가 실제로 가능하지만 우리가하는 일에서 큰 엉덩이 변화입니다. 나는 모든 사람들이 아직 그것을 멍청이 생각하지 않습니다. 나는 아직도 그것을 알아내는 것을 알고있다 ...


2

Apress의 Steve Sanderson의 최근에 출판 된 'Pro ASP.NET MVC'[1] [2]는 맞춤형 HtmlHelper 확장을 만드는 또 다른 대안을 제안합니다. 그의 샘플 (110 페이지의 4 장에서)은 페이징 된 목록의 예를 사용하지만 상황에 따라 쉽게 조정할 수 있습니다.

public static string PostNavigator(this HtmlHelper html, Post previous, Post next, Func<int, string> pageUrl)
{
    StringBuilder result = new StringBuilder();

    if (previous != null || next != null)
    {
        result.Append("<div>");

        if (previous != null)
        {
            result.Append(@"<span class=""left"">");
            TagBuilder link = new TagBuilder("a");
            link.MergeAttribute("href", pageUrl(previous.Id));
            link.InnerHtml = String.Format("<< {0}", html.Encode(previous.Subject));
            result.Append(link.ToString());
            result.Append("</span>");
        }

        if (next != null)
        {
            if (previous != null)
            {
                result.Append(" ");
            }

            result.Append(@"<span class=""right"">");
            TagBuilder link = new TagBuilder("a");
            link.MergeAttribute("href", pageUrl(next.Id));
            link.InnerHtml = String.Format("{0} >>", html.Encode(next.Subject));
            result.Append(link.ToString());
            result.Append("</span>");
        }

        result.Append("</div>");
    }

    return result.ToString();
}

다음과 같은 코드로 뷰에서 호출합니다.

<%= Html.PostNavigator(ViewData.Model.PreviousPost, ViewData.Model.NextPost, id => Url.Action("View", new { postId = id })) %>

[1] http://blog.codeville.net/2009/04/29/now-published-pro-aspnet-mvc-framework-apress/

[2] http://books.google.com/books?id=Xb3a1xTSfZgC


2
와우, 코드에서 끔찍한 마크 업 ... Bleck.
FlySwat

'PostNavigator'가 변경되지 않고 마크 업이있는 재사용 가능한 위젯 (또는 WebControl 인 경우)이며 CSS 규칙에 따라 스타일이 지정된 경우 어떻게 그렇게 끔찍한 해결책입니까?

@GuyIncognito : 동의합니다. 이것은 WebControl 및 깨끗한 솔루션과 유사합니다. 어느 시점에서 HTML 문자열을 많이 생성해야합니다. 이와 같은 확장 방법은 좋은 솔루션입니다.
gbc

1

Phil Haack의 게시물을보고 싶었지만 여기에 없었으므로 http://blog.wekeroad.com/blog/i-spose-ill-just-say-it-you-should 에서 잘라서 붙여 넣습니다. 주석 섹션의 -learn-mvc /

Haacked-2009 년 4 월 23 일-Rob, 당신은 폭동입니다! :) 사람들이 MVC에서 스파게티 코드를 작성하고 "봐! 스파게티!"라고 말하면 재미 있어요. Web Forms에서도 스파게티 코드를 작성할 수 있습니다! 레일, PHP, Java, Javascript로 작성할 수 있지만 Lisp에서는 작성할 수 없습니다. 그러나 아직 Lisp로 아무것도 쓸 수 없기 때문입니다. 그리고 스파게티 코드를 작성할 때 마카로니를 기대하는 내 접시를 보지 못합니다. 클래식 ASP와 비교할 때 사람들이 자주하는 요점은 클래식 ASP를 가진 사람들이 우려를 혼합하는 경향이 있다는 것입니다. 페이지에는 사용자 입력 처리 기능이있는 뷰 로직과 모델 코드 및 비즈니스 로직이 모두 혼합 된 뷰 로직이 있습니다. 그게 스파게티에 관한 것입니다! 하나의 큰 혼란에 모든 우려를 혼합. ASP.NET MVC를 사용하면 패턴을 따를 경우 그럴 가능성이 줄어 듭니다. 네, 여전히 뷰에 약간의 코드가있을 수 있지만 모든 뷰 코드 일 것입니다. 이 패턴은 사용자 상호 작용 코드를 넣지 않도록 권장합니다. 컨트롤러에 넣으십시오. 모델 코드를 모델 클래스에 넣습니다. 그곳에. 스파게티가 없습니다. 오오 토로 초밥입니다. :)


1

나도; ASP.NET MVC보다는 Silverlight에 시간을 할애했습니다. MVC 1.0을 사용해 보았으며 며칠 전에 최신 2.0 베타 1 릴리스를 살펴 보았습니다.

ASP.NET MVC가 웹 양식보다 나은 방법을 느낄 수 없습니다. MVC의 판매 포인트는 다음과 같습니다.

  1. 단위 (테스트)
  2. 디자인 (뷰)과 로직 (컨트롤러 + 모델)을 분리
  3. 뷰 스테이트가없고 요소 ID 관리 개선
  4. RESTful URL 등 ...

그러나 코드 숨김을 사용하여 webform. 테마, 스킨 및 리소스는 이미 디자인과 논리를 분리하기에 완벽합니다.

Viewstate : 클라이언트 ID 관리가 ASP.NET 4.0에서 제공됩니다. 단위 테스트에만 관심이 있지만 단위 테스트는 웹 양식에서 ASP.NET MVC로 전환 해야하는 이유가 충분하지 않습니다.

어쩌면 내가 말할 수 있습니다 : ASP.NET MVC는 나쁘지 않지만 webform은 이미 충분합니다.


-1

Preview 3가 나온 이후로 MVC를 사용해 왔으며 여전히 팀 개발 영역에서 상당히 도움이되는 어려움이 있습니다. 3 명의 사람들이 하나의 웹폼 페이지에서 작업하도록하세요. 그러면 벽에 머리를 두드리는 개념을 이해할 수 있습니다. 뷰 페이지의 디자인 요소와 상주 Linq 신을 이해하는 개발자와 함께 모델을 작동시키는 동안 컨트롤러에서 모든 것을 하나로 모을 수 있습니다. 나는 관심의 분리가 매우 쉬운 영역에서 결코 발전 할 수 없었습니다.

ASP.Net MVC의 가장 큰 판매 지점 -StackOverflow는 MVC 스택에서 실행됩니다.

그 말은 ... 귀하의 코드는 일반적으로보기 페이지에서하는 것보다 훨씬 더 예쁘습니다. 또한 내가 일하는 사람 중 하나가 HTML 도우미를 태그 라이브러리에 래핑하는 작업을하고 있습니다. <% = Html.RandomFunctionHere () %> 대신 다음과 같이 작동합니다

<hh : 무작위 기능 />

MVC 팀이 더 나은 작업을 수행 할 것이라고 확신하기 때문에 MVC 팀이 어느 시점에 다가 가기를 바랍니다.


1
"... 저와 함께 일하는 사람 중 하나가 HTML 도우미를 태그 라이브러리에 래핑하는 작업을하고 있습니다. <% = Html.RandomFunctionHere () %> 대신 <hh : randomfunction />와 같이 작동합니다." "RandomFunctionHere ()"메소드를 호출하는 것은 단지 메소드 호출입니다. 그것은 마크 업이 아니며, 그 사실을 태그처럼 보이는 것으로 추상화 하면 요점이 빠져있는 것 같습니다. 만약 내가 그 코드를보고있는 개발자라면, 나는 그것을 커스텀 태그보다 메소드로 보길 원할 것이다.
Jason Bunting


-17

ASP.NET MVC 구현은 끔찍합니다. 제품이 suck니다. 나는 몇 가지 데모를 보았고 MSFT를 부끄럽게 생각합니다 ... 나는 그것을 쓴 사람들이 나보다 똑똑하다고 확신하지만 Model-View-Controller가 무엇인지 모르는 것처럼 거의 .

MVC를 구현하려는 사람은 MSFT에서 새로운 것을 시도하는 사람뿐입니다. 내가 본 데모에서 발표자는 사과를했습니다 ...

나는 MSFT의 열렬한 팬이지만 MVC 구현을 방해 할 이유가 없다고 말해야합니다. Web Forms를 사용하거나 웹 개발을 위해 jquery를 사용하십시오.이 가증을 선택하지 마십시오.

편집하다:

Model-View-Controller 아키텍처 디자인 패턴의 목적은 비즈니스 규칙과 도메인을 프레젠테이션에서 분리하는 것입니다. 구현 한 모든 Web Forms 프로젝트에서 패턴을 성공적으로 사용했습니다. ASP.NET MVC 제품은 실제 건축 디자인 패턴에 적합하지 않습니다.


3
사이트에 따라 MVC는 많은 추가 작업없이 바로 사용할 수있는 매우 강력한 도구입니다. 나를 위해, 나는 웹 마크가 간단한 웹 사이트의 마크 업에 대해 할 수있는 혐오는 단지 마크 업을 제어하기 위해 사용하고 있습니다.
Tom Anderson

MVC는 WebForms를 선호하도록 설계된 ASP.NET의 금형에 적합하기 때문에 실제로 매우 훌륭하다고 말하고 싶습니다.
Hugoware

@tom-당신이 뭔가에 대해 긍정적 인 의견을 서 두어야한다면 ... 사이트에 따라 ... 당신은 이미 얇은 얼음 위에 서 있습니다. 요구 사항이 ASP.NET MVC를 사용하여 사이트를 개발 해야하는 경우 좋은 선택 일 수 있지만 다른 것의 경우 나쁜 선택처럼 보입니다.
mson

4
나는 초콜릿을 좋아하고 바닐라보다 선호합니다. 누구든지 그것에 대해 논쟁하고 싶습니까?
Jason Bunting

4
@Jason 초콜렛은 끔찍합니다. 그냥 평범한 SUCKS ..
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.