MVC: Я делаю это правильно?

Question

Эй, люди. Я не знаю, понял ли я на 100% концепцию MVC.

У меня проблемы с отношением Model-View.

Чтобы представить данные пользователю, представление должно иметь доступ к данным, верно? Получается ли этот доступ путем прямой передачи всех необходимых данных в представление (и когда представление хранит данные в своем классе как атрибут) или просто получает данные, «проанализированные» как строки, целые числа и т. нужен (как пользователь перемещается по GUI) с контроллера, вызывая события? Я чувствую, что это немного излишнее событие, так как данные не изменились.

Кстати, вы можете сказать мне, что эти стрелки на диаграмме MVC в Википедии делают на реальном примере? Спасибо.

Answer 1

Модель является центральным, авторитетным хранилищем информации. В качестве примера возьмите церковный справочник своего собрания.

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

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

Обратите внимание, что в некоторых случаях представления и контроллеры могут быть одним и тем же, или представления для одной модели, контроллеры для другой и т. Д., И т. Д. Например, член церкви может просматривать данные других членов или изменять их. владеть, взаимодействуя с моделью.

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

Существует два основных способа взаимодействия модели с видами: толкание и вытягивание. Нажав , данные задействуют данные со стороны модели, чтобы узнать, какие представления следует уведомлять при обновлении части информации. Извлечение данных включает в себя интеллект на стороне представления, чтобы знать, как и когда смотреть на модель для изменений в данных, которые ее больше всего интересуют.

Answer 2

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

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

Answer 3

Чтобы развить предыдущие ответы, вот очень простое приложение, показывающее различное использование каждой из рассматриваемых областей. Это приложение хранит и отображает автомобили, которые продал продавец.

Сначала у нас есть наши модели:

public class Car
{
    int Id { get; set; }

    string make { get; set; }
    string colour { get; set; }
}

public class Salesman
{
    int Id { get; set; }

    string name { get; set; }
    IList<Sale> Sales { get; set; }
}

public class Sale
{
    int Id { get; set; }

    int CarId { get; set; }
    int SalesmanId { get; set; }

    decimal Amount { get; set; }
}

Теперь предположим, что нам нужно отобразить страницу, на которой указаны все автомобили, которые продал конкретный продавец. Для этого мы решаем, какие данные нам понадобятся на странице, например, Имя продавца и список автомобилей, которые он продал. Мы создаем Просмотр модели этих данных.

public class SalesViewModel
{
    string SalesmanName { get; set; }
    List<Car> CarsSold { get; set; }
}

Теперь нам нужно построить (заполнить) эту модель View в нашем контроллере, готовую к передаче в наш View.

public ActionResult SalesmanCarsSold(int salesmanId)
{
    SalesViewModel salesVm = new SalesViewModel();

    using (var dbCtx = new dbCtx())
    {
        salesVm.SalesmanName = dbCtx.GetSalesmanById(salesmanId).Name;
        salesVm.CarsSold = dbCtx.GetCarsSoldBySalesmanId(salesmanId);
    }

    return View(salesVm);
}

Теперь все, что нужно сделать, это просто записать эти данные на наш взгляд, например,

@model MyProject.Web.Models.ViewModels.SalesViewModel

Salesman Name: @Model.SalesmanName

@foreach(var car in Model.CarsSold)
{
    Car: @car.make
}

Answer 4

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

У вас всегда должен быть отдельный уровень бизнес-логики (или уровень сервисов), к которому контроллеры MVC имеют доступ для выполнения бизнес-логики, а также отдельный уровень доступа к данным (или репозитории), доступ к которому есть только у уровня сервисов / бизнес-логики. извлекать данные из базы данных.

В вашем типичном приложении MVC у вас может быть несколько моделей представления, представляющих один и тот же объект уровня данных (который обычно представляет таблицу базы данных). Например, у вас может быть 2 представления для представления информации о человеке; один представляет собой сводный вид, а другой - подробный вид. В вашем приложении MVC у вас будет 2 модели просмотра, т.е. PersonSummary и PersonDetail, которые заполняются из одной и той же таблицы Persons на уровне данных и возвращаются вашему действию контроллера, когда ваш контроллер вызывает методы (например, GetPersonSummary () и GetPersonDetails ()). в классе PersonService (уровень бизнес-логики).

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

В любом случае, это были мои 2цента! Надеюсь, это поможет вам лучше понять MVC ...

Answer 5

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

Сама модель не зависит напрямую от вида, скорее, представление отправляет события или иным образом использует контроллер для изменения модели. Таким образом, вы можете иметь общую «общую» модель, общий контроллер, который модифицирует указанную модель и все виды представлений, которые отображают части указанной модели способами, которые имеют смысл.

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

В Flex / AS3, которую я выбрал в среде разработки, это очень легко сделать, вы создаете файл Model.as, который имеет статическую переменную с названием say modelLocator, которая сама по себе является новой Model (), в Model.as вы определите все ваши общедоступные переменные, в Controller.as у вас есть дескриптор модели, создав свойство (и здесь обязательно назовите его modelLocator), и в конструкторе контроллера вы можете создать экземпляр modelLocator, например, modelLocator = Model.modelLocator, сделать то же самое в затем ваш View в представлении вы просто обновляете компоненты вашего представления при изменении модели (во Flex вы можете использовать {} для привязки значений непосредственно к свойствам ваших компонентов, представления извлекаются из модели на основе сообщения из @fbereto, хорошее объяснение между прочим) ).