Должна ли сама модель делать некоторые расчеты?

Question

Я изучаю ASP.NET MVC в течение нескольких месяцев. Я узнал о представлениях и контроллерах, моделях и прочем. Для разработки вида нам всегда нужна модель. Обычно модель - это просто класс, который мы заполняем данными и передаем в представление. У меня есть вопрос: должна ли сама модель делать какие-то вычисления или она должна быть глупой?

Например, у меня есть сайт, где я загружаю Book с User с. Мой модельный класс выглядит следующим образом:

public class FormViewModel
{
  public User MyUser {get; set;}
  public Books UserBooks {get; set;}

  //Constructor here. 
  public FormViewModel(User _user, Books _userBooks)
  {
    this.MyUser=_user;
    this.UserBooks=_userBooks;
  }
}

Этот класс ничего не делает - это всего лишь шаблон. Теперь, если я изменю код следующим образом:

public class FormViewModel
{
  public User MyUser {get; set;}
  public Books UserBooks {get; set;}

  //Constructor here. 
  public FormViewModel(User _user)
  {
    this.MyUser=_user;
    this.UserBooks=_user.GetBooks();
  }
}

, какие Book s собираются, зависит от того, какой User был выбран. Теперь с ним намного проще работать.

Я просто хочу знать, что такое хороший подход в соответствии с шаблонами и практиками MVC.

Answer 1

Вы хотите разделить всю свою бизнес-логику и проверку данных в модели. Обычно это включает в себя «группирование» наборов данных и тому подобное или фильтрацию данных по некоторым критериям.

Вы хотите разделить все вызовы этих методов модели в контроллере, ответственность за которые заключается в получении и отправке данных в модель и из нее. Затем контроллер передает соответствующий набор данных в представление.

Помощники - это логика, которая используется представлением для представления логики (не бизнес-логики или проверки), такой как печать меню и т. Д.

Вид - это место, где вы будете использовать помощников (или нет, они не обязаны правильно использовать MVC, но они «помогают»: p) записывать HTML, CSS и JS в браузер. Вы также можете разделить часто используемые модули представления на частичные представления, которые можно включить в несколько представлений.

Вы можете в дальнейшем разделять вещи в ViewModel, но тогда вы выходите за пределы "строгого" MVC. В этом случае вы должны использовать ViewModel, чтобы помочь представлению взаимодействовать с моделью - в основном ViewModel - это модульный контроллер. В этом случае контроллер будет делать гораздо меньше, чем то, что он уже делает.

Однако для веб-приложений это, как правило, излишне. Поскольку веб-приложения имеют единый поток выполнения (запрос), разделение элементов на ViewModel становится ненужным. Однако в коде GUI ViewModel становится намного более полезным (поскольку GUI имеет гораздо больше, чем один поток выполнения).

Вы всегда хотите разделить бизнес-логику на Модель, точка. Помните, что вы не должны связывать свой контроллер с вашей моделью - так что вы можете использовать свою модель в другом месте на других контроллерах или даже представить ее как веб-сервис.

Надеюсь, это поможет :)

Answer 2

Проверьте это . Вы говорите о модели VIEW , а не модели домена. Это огромная разница. Модель представления должна быть тупой, это просто заполнитель для данных, который позволяет более строго типизировать ваши представления. Модель домена должна быть сердцем вашего приложения, она должна содержать ALL бизнес-логику.

Answer 3

Если у вас есть модель представления, которая отличается от модели вашего домена, вы не должны отображать модель домена в модель представления внутри модели представления. Это сделало бы класс viewmodel ответственным за более чем одну вещь. Вы можете сделать отображение в контроллере или на уровне сервиса.

Answer 4

Вы можете сделать это несколькими способами, но я бы сказал, что самый простой способ - передать ссылочный идентификатор пользователя, к которому вы пытаетесь получить доступ, к действию контроллера (как показано ниже) и позволить ему выполнить все вызовы доступа к данным.

public void GetUserAndDetails(Guid userId) { ... }

Затем в этом действии контроллера вы можете просмотреть сведения о пользователе и книги для этого пользователя, установить свойства экземпляра модели представления и вернуть его в представление для доступа.

FormViewModel model = new FormViewModel();
model.MyUser = GetUser(userId);
model.UserBooks = GetUserBooks(userId);
return View(model);

Таким образом, вид остается тупым (как и должно быть), а модель относительно проста. Это также помогает в целях тестирования.

Надеюсь, это поможет.

Answer 5

это «тупой» взгляд. все, что он делает, это отображает измененные данные.

контроллер просто выбирает данные из модели для просмотра ... опять же, контроллер - ТОЛЬКО промежуточный пункт.

модель делает все. он хранит данные и содержит классы и методы, которые ими манипулируют.

Answer 6

В общем, такая работа должна выполняться в модели. Это по нескольким причинам. Во-первых, если получение пользовательских книг требует подключения к базе данных, вы не хотите делать это из представления - это просто замедлит его. Еще одна вещь, которую следует помнить, это то, что может быть несколько представлений, и вам нужно будет продублировать этот код во всех представлениях (веб-клиенты, возможно, расширенные клиенты и т. Д.).

В шаблоне MVC представления должны быть "тупыми" частями. Это позволяет легче использовать несколько представлений и изменять представления при необходимости. Кроме того, проще тестировать код, когда для него не требуется представление, поэтому вы можете протестировать модель без вызова веб-клиента.

Jeff

Answer 7

Бизнес-логика не допускается для модели! Это плохой дизайн! Ваша логика должна быть в контроллерах, а точнее: поместить свою логику в помощники (помощники могут потреблять ваш BLL и / или DAL), а затем использовать ваши помощники в контроллерах.

Answer 8

MVC - это сам по себе шаблон. У меня действительно нет опыта работы с ASP.NET MVC, но я работал несколько раз и использовал шаблон MVC. Иногда MVC используется для других шаблонов разработки, таких как сердцебиение, память, состояние ...