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

Question

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

Например, у меня есть сайт, на котором я загружаю Book s по 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

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

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

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

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

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

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

Answer 2

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

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

Джефф

Answer 3

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

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

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

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

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

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

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

Надеется, что это помогает :)

Answer 4

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

контроллер просто извлекает данные из модели для представления ... снова контроллер находится ТОЛЬКО между ними.

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

Answer 5

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

Answer 6

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

Answer 7

Отъезд this. Вы говорите о VIEW модель, а не модель домена. Это огромная разница. Модель просмотра должна быть немой, это просто местозаполнитель для данных, который позволяет более точно набирать ваши представления. Модель домена должна быть сердцем вашего приложения, оно должно содержать ВСЕ бизнес-логика.

Answer 8

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