ASP.NET MVC 3-부분 대 디스플레이 템플릿 대 편집기 템플릿


303

따라서 제목은 그 자체로 말해야합니다.

ASP.NET MVC에서 재사용 가능한 구성 요소를 만들려면 3 가지 옵션이 있습니다 (내가 언급하지 않은 다른 옵션 일 수 있음).

부분보기 :

@Html.Partial(Model.Foo, "SomePartial")

맞춤 편집기 템플릿 :

@Html.EditorFor(model => model.Foo)

맞춤 디스플레이 템플릿 :

@Html.DisplayFor(model => model.Foo)

실제보기 / HTML과 관련하여 세 가지 구현은 모두 동일합니다.

@model WebApplications.Models.FooObject

<!-- Bunch of HTML -->

그래서 내 질문은-언제 / 어떻게 세 가지 중 하나를 사용할지 결정합니까?

내가 정말로 찾고있는 것은 질문을 만들기 전에 스스로에게 물어볼 질문 목록입니다. 대답은 사용할 템플릿을 결정하는 데 사용될 수 있습니다.

EditorFor / DisplayFor에서 더 나은 두 가지를 발견했습니다.

  1. HTML 도우미를 렌더링 할 때 모델 계층을 존중합니다 (예 : "Foo"모델에 "Bar"개체가있는 경우 "Bar"의 HTML 요소는 "Foo.Bar.ElementName"을 사용하여 렌더링되며 부분은 " ElementName ").

  2. 더 강력합니다. 예를 들어 List<T>ViewModel에 무언가가있는 경우을 사용할 수 @Html.DisplayFor(model => model.CollectionOfFoo)있으며 MVC는 컬렉션임을 확인하고 각 항목에 대해 단일 디스플레이를 렌더링 할 수 있을만큼 똑똑합니다. 고리).

또한 DisplayFor가 "읽기 전용"템플릿을 렌더링한다고 들었지만 이해할 수 없습니다. 거기에 양식을 넣을 수 없습니까?

누군가 다른 이유를 말해 줄 수 있습니까? 세 가지를 비교하는 목록 / 문서가 있습니까?


편집기 및 디스플레이 템플릿의 개념은 asp.net mvc 2 설명서에 명확하게 정의되어 있습니다. 템플릿은 특정 규칙을 준수하는 부분입니다. 이전 부분보다 템플릿을 더 좋거나 나쁘게 만드는 상황은 응용 프로그램에서 규칙을 준수 할 가치가 있는지 여부에 따라 거의 엄격하게 달라집니다.
Nick Larsen

답변:


301

EditorForvs DisplayFor는 간단하다. 이 방법의 의미는 (각각) 편집 / 삽입 및 표시 / 읽기 전용보기를 생성하는 것입니다. 사용 DisplayFor(당신이 div의 및 모델 값을 포함 스팬을 생성 할 때 즉) 데이터를 표시 할 때. 사용 EditorFor(폼 내부에 입력 태그를 생성 할 때 예) 데이터를 삽입 / 편집 할 때.

위의 방법은 모델 중심입니다. 그들은 (계정에 모델 메타 데이터를 취할 것입니다 예를 들어 당신이 모델 클래스에 주석을 달 수 있음이 수단 [UIHintAttribute]또는 [DisplayAttribute]이 모델에 대한 UI를 생성하기 위해 선택한 도착하는 템플릿에 영향을 미칠 것입니다. 또한 일반적으로 (데이터 모델, 즉 모델을 사용되는 데이터베이스의 행을 나타냅니다.)

반면 Partial올바른 뷰를 선택하는 데 주로 관심이 있다는 관점에서 뷰 중심입니다. 뷰가 제대로 작동하기 위해 모델이 반드시 필요한 것은 아닙니다. 사이트 전체에서 재사용되는 공통 마크 업 세트 만 가질 수 있습니다. 물론이 부분의 동작에 영향을주는 경우가 종종 있으며,이 경우 적절한 뷰 모델을 전달할 수 있습니다.

당신은 @Html.Action여기에 언급 할 가치가있는 것에 대해 묻지 않았습니다 . Partial컨트롤러 하위 작업을 실행 한 다음 뷰 (일반적으로 부분 뷰)를 렌더링한다는 점에서 보다 강력한 버전으로 생각할 수 있습니다. 하위 조치가 부분보기에 속하지 않은 추가 비즈니스 로직을 실행할 수 있기 때문에 이는 중요합니다. 예를 들어 장바구니 구성 요소를 나타낼 수 있습니다. 이를 사용하는 이유는 애플리케이션의 모든 컨트롤러에서 쇼핑 카트 관련 작업을 수행하지 않기 위해서입니다.

궁극적으로 선택은 응용 프로그램에서 모델링하는 대상에 따라 다릅니다. 또한 믹스 앤 매치가 가능하다는 것을 기억하십시오. 예를 들어, EditorFor도우미 를 호출하는 부분보기가있을 수 있습니다 . 실제로 응용 프로그램이 무엇인지, 반복을 피하면서 최대 코드 재사용을 장려하기 위해 응용 프로그램을 팩토링하는 방법에 달려 있습니다.


4
그것은 내가 찾던 정확한 대답입니다. 실제로 나는 당신이 와서 이것에 대답 할 것이라는 사실을 알고있었습니다. :) 감사합니다 marcin.
RPM1984

주석을 사용하여 단일 속성에 대한 표시 템플릿 및 편집기 템플릿을 지정하는 방법은 무엇입니까?
stormwild

3
@stormwild는 관례를 사용하고 템플릿과 관련된 모델 이름 (/Views/DisplayTemplates/MyModel.cshtml)을 지정하거나 UIHint 주석을 사용하여 템플릿을 명시 적으로 지정합니다.
Tom Wayson

재사용 가능한 "사용자 등록"마법사를 만들기 위해 선택해야 할 조언이 있습니까? 가능한 경우 이러한 뷰 (및 컨트롤러)를 별도의 어셈블리로 만들고 싶습니다. 일명, 여러 팀 사이에 이러한 resuable mvc 양식 / 컨트롤러를 재배포하는 방법. (우리는 핸들 사용자 / 저장 (webapi 서비스)에 대한 하나의 방법을 만들었습니다 ...하지만 각 팀은 자신의 MVC 페이지를 만드는 : <감사합니다.
granadaCoder

해당 템플릿을 어디에 저장합니까? Shared / EditorTemplates에 저장해야합니까, 아니면 현재 컨트롤러 폴더에 직접 저장할 수 있습니까 (필요한 경우에만)?
Santhos

15

당신은 확실히 수있는 사용자 정의 DisplayFor편집 가능한 폼을 표시 할 수 있습니다. 하지만 규칙은입니다 DisplayFor될 수 readonlyEditorFor편집 할 수 있습니다. 협약을 고수하면 무엇을 전달하든 DisplayFor동일한 유형의 일을 할 수 있습니다.


2
디스플레이 템플릿과 편집기 템플릿을 언제 사용해야하는지에 대한 의문이 전혀 없다고 생각합니다. 실제 질문은 언제 템플릿과 부분을 사용해야하는지 나타납니다. 당신의 대답은 이것을 완전히 놓칩니다.
Joshua Hayes

19
@Joshua-나는 그것에 대해 몇 가지 질문이 있다고 생각합니다. "DisplayFor가"읽기 전용 "템플릿을 렌더링한다고 들었지만 이해가되지 않습니다. 거기에 양식을 넣을 수 없습니까?"
Robert Levy 2016 년

13

내 2c 가치를 부여하기 위해 프로젝트는 여러 jQuery 탭이있는 부분보기를 사용하고 각 탭은 자체 부분보기로 필드를 렌더링합니다. 이것은 일부 탭이 공통 필드를 공유하는 기능을 추가 할 때까지 잘 작동했습니다. 이에 대한 첫 번째 접근 방식은 이러한 공통 필드로 다른 부분보기를 작성하는 것이었지만 EditorFor 및 DropDownListFor를 사용하여 필드를 렌더링하고 드롭 다운 할 때 매우 복잡했습니다. 고유 한 ID와 이름을 얻으려면 필드를 렌더링 한 상위 부분보기에 따라 접두어로 필드를 렌더링해야했습니다.

    <div id="div-@(idPrefix)2" class="toHide-@(idPrefix)" style="display:none">
    <fieldset>
        <label for="@(idPrefix).Frequency">Frequency<span style="color: #660000;"> *</span></label>

        <input name="@(idPrefix).Frequency"
               id="@(idPrefix)_Frequency"
               style="width: 50%;"
               type="text"
               value="@(defaultTimePoint.Frequency)"
               data-bind="value: viewState.@(viewStatePrefix).RecurringTimepoints.Frequency"
               data-val="true"
               data-val-required="The Frequency field is required."
               data-val-number="The field Frequency must be a number."
               data-val-range-min="1"
               data-val-range-max="24"
               data-val-range="The field Frequency must be between 1 and 24."
               data-val-ignore="true"/>

        @Html.ValidationMessage(idPrefix + ".Frequency")

        ... etc

    </fieldset>
</div>

꽤 추악 해 졌기 때문에 에디터 템플릿을 대신 사용하기로했습니다. 공통 필드가있는 새 뷰 모델을 추가하고 일치하는 편집기 템플릿을 추가 한 후 서로 다른 상위 뷰의 편집기 템플릿을 사용하여 필드를 렌더링했습니다. 편집기 템플릿은 ID와 이름을 올바르게 렌더링합니다.

간단히 말해서 편집기 템플릿을 사용해야하는 강력한 이유는 몇 가지 공통 필드를 여러 탭으로 렌더링해야하기 때문입니다. 부분 뷰는이를 위해 설계되지 않았지만 편집기 템플릿은 시나리오를 완벽하게 처리합니다.


1
탭을 사용하여 비슷한 문제가 발생하여 Steve Sanderson의 BeginCollectionItem을 사용하여 고유 한 컨트롤 ID를 생성했습니다. blog.stevensanderson.com/2010/01/28/…
Wilky

1

다음과 같은 _partial경우 뷰 접근 방식을 사용하십시오 .

  1. 중심 논리보기
  2. _partial이 뷰에서만 모든 뷰 관련 HTML 을 유지하는 것. 템플릿 방법에서는 "메인 헤더 또는 외부 테두리 / 설정과 같은 일부 HTML을 템플릿보기 외부에 유지해야합니다.
  3. 를 사용하여 (제어기에서) 논리로 부분 뷰를 렌더링하려고 URL.Action("action","controller")합니다.

템플릿을 사용해야하는 이유 :

  1. 를 제거하고 싶습니다 ForEach(Iterator). 템플릿은 모델을 목록 유형으로 식별하기에 충분합니다. 자동으로 수행됩니다.
  2. 모델 중심 논리. 템플릿 폴더의 동일한 표시에서 여러보기가있는 경우 렌더링은 전달 된 모델에 따라 다릅니다.

1

지금까지 언급되지 않은 또 다른 차이점은 템플릿이하는 동안 partialview 모델 접두사를 추가하지 않는다는 것입니다 여기서 문제입니다

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.