Совет по дизайну дизайна для ASP.NET MVC

Question

Я сейчас в процессе преобразования некоторых небольших личных веб-сайтов из WebForms в MVC. С существующими сайтами схема базы данных прочная, но я никогда не занимал время для создания правильных данных/бизнес-моделей/слоев. Все страницы aspx говорили с базой данных напрямую, используя различные виды и хранимые процедуры, которые были созданы по мере необходимости для удобства. С MVC я теперь пытаюсь «сделать это правильно», как они говорят, и использовать такие вещи, как LINQ to SQL и/или Entity Framework, для создания правильной модели данных или моделей для приложения.

Мой вопрос вращается вокруг того, какие цели я должен иметь для создания моделей данных. Я читал различные статьи, связанные с шаблонами, и понимаю, что в конечном итоге ответ, вероятно, будет зависеть от характеристик моих данных. Но вообще-то я должен попытаться построить более крупные модели, которые охватывают как можно большую часть базы данных, так что есть только один способ взаимодействия с заданным набором таблиц? Или мне нужно создавать более мелкие пользовательские модели для каждого MVC-представления, которые содержат только данные и доступ к этому представлению?

Answer 1

Нужно ли создавать небольшие пользовательские модели для каждого MVC-представления, которые содержат только данные и доступ к этому представлению?

Это, вероятно, было бы лучше.

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

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

Answer 2

Я хотел бы пойти на модели, представляющей реальную логику данных в пределах текущей системы и ваши контроллеры возвращают часть модели, которая вид потребности, такие как:

Контроллер:

public ActionResult index() 
{ 
    var ListOfObjects = DataHelper.GetAll(); 
    ViewData.Add(ListOfObjects); 
    return View(); 
} 

public ActionResult ViewObject(int id) 
{ 
    var Object= DataHelper.GetObject(); 
    ViewData.Add(Object); 
    return View(); 
} 

public ActionResult ViewObjectChild(int Objectid, int ChildId) 
{ 
    var Child= DataHelper.GetChildObject(Objectid, ChildId); 
    ViewData.Add(Child); 
    return View(); 
} 

On вид

/

<% var myListOfObjects = ViewData.Get<IList<Object>>(); %> 

/ViewObject/1/

<% var myobject= ViewData.Get<Object>(); %> 

/ViewChild/1/1/

<% var myChild = ViewData.Get<Child>(); %> 

Примечание Я использовал MVC CONTRIB напечатал функции Я очень рекомендую их.

Answer 3

Как правило, у вас будет одна всеобъемлющая модель домена для базы данных. Вы можете использовать (изменить/добавить/удалить/etc.) Модель домена на уровне обслуживания или контроллере, если это небольшое приложение.

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

Например:

Ваша модель может включать в себя:

public class Car() 
{ 
    public string Model; 
} 

public class Driver() 
{ 
    public string Name; 
} 

Вы хотите вид, чтобы вывести имя и модель автомобиля, и вы должны пройти как автомобиль и водитель модели объектов Посмотреть.

Вместо того, чтобы посылать две модели объектов непосредственно от контроллера к представлению, вы можете создать объект, который содержит только данные, что вам нужно:

public class CarAndDriverViewModel() 
{ 
    public string CarMake; 
    public string DriverName; 
} 

Вы бы заселить этот объект из данных домена и прохода что к мнению. И вид будет:

model.DriverName + ": " + model.CarMake 

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

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