Должны ли параметры ASP.NET MVC быть параметризованы

Question

В asp.net mvc я думал, что было бы более выгодно указывать параметризованные конструкторы в классах представления в отличие от использования ViewData для передачи данных в представление. Таким образом, класс представления может быть создан в действии и возвращен оттуда как реализация IView для возможного рендеринга клиенту платформой.

// 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;}
}

Я задаю этот вопрос, потому что лично считаю строго типизированные представления бессмысленными, поскольку нет ни 1, ни 0, а n количества объектов, которые я хотел бы передать представлению из действия. Я также нахожу коллекцию ViewData слишком «нетипизированной», чтобы действительно хорошо сочетаться со строго типизированным миром .net.

Конструктор параметризации или даже открытые свойства в представлении позволили бы разработчику представления указать контракт, какие данные необходимы для отображения представления или могут быть отображены в представлении. Этот подход будет эффективно инкапсулировать представление.

Почему это плохой дизайн? Какие преимущества дает «коллекция типизированных данных» / «строго типизированное представление», «способ» передачи данных из действия в представление. Кто-нибудь думает, что это будет хорошей идеей?

---

обновление

У меня изменилось сердце. Я понял, что это действительно рендеринг. Очень хорошим подходом к проектированию является внедрение презентационных моделей , которые представляют пользовательские интерфейсы, доступные в вашем приложении.

Если что-то можно показать или нет, то в вашей модели презентации должен быть логический тип. Если что-то может отображать текст, в вашей модели презентации должна быть строка для этого. Модель представления не является анемичной , поскольку вы используете ее для инкапсуляции логики вашего пользовательского интерфейса. Например, если поле пустое, возможно, какое-то другое поле отображается серым цветом. Это логика представления, и она описывает, как работает ваш конкретный пользовательский интерфейс.

Как только модель представления была введена, классы общих страниц работают нормально, вы просто передаете представление правильной модели представления. Модели презентаций позволяют вам очистить код в вашем представлении, а также обеспечивают переносимость. Если кто-то решит внедрить в winforms, им нужно будет только привязать свой пользовательский интерфейс к модели презентации.

В любом случае, я просто хотел продолжить, потому что я больше не согласен с моим первоначальным предложением. Я принял ответ Трэвиса, потому что это по сути то, что он предложил.

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;}
}

Извините за придуманный пример, но я думаю, вы понимаете, к чему я стремлюсь. Таким образом, вы можете объединить все данные, связанные с представлением, в один объект, который можно легко протестировать и поддерживать. Это также имеет то преимущество, что строго типизированные представления с использованием обобщений.

Я предпочитаю это вашему предложению параметризованных конструкторов, потому что его цель ясна, и создание и агрегация этих данных будут в одном месте, которое, вероятно, будет легче поддерживать.