ASP.NET MVC 뷰를 매개 변수화해야 함

Question

asp.net mvc에서 필자는 ViewData를 사용하여 뷰에 데이터를 전달하는 것과 달리 뷰 클래스에 매개 변수화 된 생성자를 지정하는 것이 유리할 것이라고 생각해 왔습니다. 이 방식으로 뷰 클래스는 액션에서 인스턴스화 될 수 있고 프레임 워크에 의해 클라이언트에 최종 렌더링을위한 IView의 구현으로 리턴 될 수 있습니다. 1 또는 0하지만 이없는 나는 개인적으로 강력한 형식의 전망이 무의미 발견 때문에

// An example of an action that returned one of two 
// views while passing a data objects from the current 
// scope. 
IView MyAction(discriminator){ 
    if(discriminator){ 
    return new MyView(SomeVal, SomeVal2) 
    }else{ 
    return new AnotherView(SomeVal1) 
    } 
} 

// An Example Definition for IView 
public interface IView{ 
    Render(stream OutputStream); 
} 

// An Example View Code Behind/Partial Class 
public partial class AnotherView{ 
    public AnotherView(string GimmeData){ 
    this.GimmeData = GimmeData 
    } 

    // This value could be accessed in the markup like: 
    // <%=this.GimmeData%> 
    public string GimmeData {get; set;} 
} 

내가이 질문을 제기 N 나는 액션에서보기에 전달하고자하는 객체의 수. 또한 ViewData 컬렉션은 .net 강하게 유형화 된 세계와 실제로 잘 어울리는 너무 "형식이 지정되지 않은"컬렉션을 찾습니다.

매개 변수 생성자 또는보기의 공용 속성을 사용하면보기의 구현자가보기를 렌더링하는 데 필요한 데이터 계약을 지정할 수 있으며보기에서 렌더링 할 수 있습니다. 이 접근법은 효과적으로 뷰를 캡슐화합니다.

왜 이것이 나쁜 설계입니까? 작업에서보기로 데이터를 전달하는 "보기 데이터 수집"/ "강력한 형식보기" "방식"과 함께 어떤 이점이 제공되는지. 아무도 이것이 좋은 생각이라고 생각합니까?

---

내가 마음의 변화 있었다

업데이트합니다. 내가보기에 뷰는 렌더링에 관한 것입니다. 아주 좋은 디자인 접근 방식은 응용 프로그램에서 사용할 수있는 사용자 인터페이스를 나타내는 Presentation Models을 소개하는 것입니다.

표시 할 수 있거나 표시 할 수없는 항목이 있으면 프레젠테이션 모델에 부울이 있어야합니다. 텍스트가 표시 될 수있는 경우 프레젠테이션 모델에 해당 문자열이 있어야합니다. 프레젠테이션 모델은 UI의 논리를 캡슐화하기 위해 사용하기 때문에 anemic이 아닙니다. 예를 들어 필드가 비어 있으면 다른 필드가 회색으로 표시됩니다. 이것은 프리젠 테이션 로직이며 특정 UI가 작동하는 방식을 설명합니다.

프레젠테이션 모델이 도입되면 일반 페이지 클래스가 정상적으로 작동하므로 올바른 프레젠테이션 모델을보기 만 전달하면됩니다. 프리젠 테이션 모델을 사용하면보기에서 코드를 정리하고 이식성을 제공 할 수 있습니다. winforms에서 구현하기로 결정했다면 UI를 프레젠테이션 모델에 바인딩하기 만하면됩니다.

어쨌든 더 이상 원래 제안에 동의하지 않아서 후속 조치를 원했습니다. 나는 Travis의 대답을 받아 들였다. 왜냐하면 이것이 본질적으로 그가 제안한 것이기 때문이다.

Answer 1

관습에서는 일반적으로보기에 필요한 데이터를 캡슐화하는보기 모델을 제공합니다. 그런 다음이 강력한 형식의 객체를보기에 전달할 수 있습니다. 따라서 예를 들어,이처럼 보이는 BlogDisplay 객체가 될 수 있습니다

public object BlogDisplayPage { 
    public string PageTitle {get; set;} 
    public BlogEntry Content {get; set;} 
    public IList<Comment> Comments {get; set;} 
    public IList<BlogEntry> RelatedEntries {get; set;} 
    public IList<BlogEntry> PreviousEntries {get; set;} 
} 

변명 예제의 contrivedness을,하지만 난 당신이 내가 얻을 위해 노력하고있어 이해 생각합니다. 이렇게하면 쉽게 검사 및 유지 관리 할 수있는 하나의 객체에서 View와 관련된 모든 데이터를 가질 수 있습니다. 또한 제네릭을 사용하여 강력한 형식의 뷰를 갖는 이점이 있습니다.

의도가 명확하고 매개 변수화 된 생성자의 제안이 해당 데이터의 생성 및 집계가 한 곳에서 이루어지기 때문에 유지 관리가 더 쉽기 때문에이 방법을 선호합니다.