MVC Partial Views, Models and more

Question

Я довольно новичок в ASP.NET MVC, и сейчас я пытаюсь понять некоторые из концепций дизайна. Одна вещь, в которой я сейчас застрял, - это как (лучше всего) справиться с ситуацией, подобной описанной ниже.

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

Теперь у меня есть форма ORM, такая как Entity Framework, LINQ to SQL или что-то другое, которое отображает таблицы базы данных tblCategory и tblMovie соответственно в категории и в категории Movie. Эти объекты находятся в пространстве имен MyMVCApp.Data.Entities. Затем я использую шаблон репозитория, расположенный в пространстве имен MyMVCApp.Data, чтобы инкапсулировать запросы (через LINQ) в отношении этих объектов, чтобы вернуть наши объекты модели.

Вот где мой первый вопрос. Должен ли репозиторий возвращаться к объектам модели модели или объектам домена, которые затем расширяются для создания объектов модели представления? В моем наивном уме я вижу объекты, возвращенные из ORM, как просто контейнеры для данных с объектами домена, содержащими бизнес-логику. Так что, должно быть, здесь есть абстракция?

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

Эта модель была бы заполнена где-то. Это мой второй вопрос. Скажем, мое предположение верное, и просто объекты данных возвращаются из ORM. Теперь у меня есть пространство имен/проект под названием MyMVCApp.Core.Model (или тому подобное) с некоторыми объектами домена, такими как объекты Movie и Category, упомянутые в предыдущем абзаце. Имеют ли эти сущности методы для их извлечения данных из ORM и заполняют себя? Или репозиторий извлекает эти модели заполненных сущностей? И еще один вопрос по этой части, если у меня есть объект Movie и Customer в моем ORM, приемлемо ли иметь объекты домена одинаковыми?

Наконец, я предполагаю, что контроллер теперь имеет этот заполненный список объектов Category и Movie и передает его обратно в представление. Я предполагаю, что лучше всего, чтобы каждый из разделов, описанных в начале, был частичным видом и передавал населенную модель каждому из них? Таким образом, это может быть IndexController, который извлекает заполненный объект CategoryMovies, передавая его частичным представлениям категорий и частичному просмотру фильмов. Затем мне нужно каким-то образом определить выбранную категорию (quesrystring?) И отобразить соответствующий список фильмов в этой категории в представлении.

ОК, поэтому, если кто-то добрался до этого момента в моих промах, я сделаю глубокий поклон. Надеюсь, я достаточно подробно объяснил свои смешные мысли и вопросы, чтобы кто-то мог дать какое-то просветление.

Спасибо, что посмотрели! :-)

Answer 1

Прежде всего, я думаю, вам стоит только начать с простого проекта и попробовать различные сценарии, которые вы изобразили в своем длинном вопросе :). В камне ничего не написано, вы можете использовать любую архитектуру с помощью datalayers и сервисов или что угодно, вам нравится!

Или репозиторий извлекает эти модели населенных сущностей?

Я бы сказал, да. Ваш контроллер захватывает их из службы и получает их, заполняет и все, и просто перемещает их в представление для отображения.

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

И снова я думаю, что вы на правильном пути;).

Answer 2

Поскольку вы не упомянули об этом, я предполагаю, что вы новичок в концепциях DDD. DDD приветствует «M» в MVC, размещая логику там, где она принадлежит. И, я думаю, здесь можно применить хорошую сумму.

В строгой форме DDD я бы использовал ваш пример фильма как совокупный корень (концепция DDD). Внутри фильма у вас будет бизнес-логика (методы), которая будет получать категории и связанные с ними объекты, непосредственно связанные с фильмом (т. Е. Категории-это-фильм-принадлежит-в). Это предполагает, что список «категория» Вы хотите, чтобы отобразить список категорий этот фильм в.

public class Movie 
{ 
    private IList<Category> _categories; 
    public IList<Category> FetchCategories() 
    { 
     // you can lazy-load here, use Linq-to-Sql, etc. 
     return _categories; 
    } 
    public void AddCategory(Category c) 
    { 
     _categories.Add(c); 
    } 
} 

Конечно, вы можете относиться к категории как Value Object (VO, концепция DDD) здесь, если вы не У них есть личность.

Теперь, что становится более интересным, если вы хотите сохранить личность в своих категориях, рассматривая их как совокупные корни с несколькими сущностями и отношениями с другими ВО и другими. В этом случае вы хотели бы использовать концепцию DDD Services для объединения двух агрегатов в запрошенную вами модель, которую вы хотите передать своему контроллеру. Это позволяет создавать бизнес-правила по загрузке категорий.

public class Movie 
{...} 
public class Category 
{...} 
public class MovieCategory : Movie 
{ 
    private IList<Category> _categories; 
    public IList<Category> Categories 
    { 
     get 
     { 
      return _categories; 
     } 
     internal set 
     { 
      _categories = value; 
     } 
    } 
} 
public class MovieCategoryService 
{ 
    public MovieCategory FetchMovieCategoryByMovieId(int id) 
    { 
     MovieCategory mc = _movieRepository.FetchMovie(id); 
     // do some logic here, some checks, etc 
     // to obtain your Categories list. Maybe querystring? 
     IList<Category> cats = ...; 
     mc.Categories = cats; 

     return mc; 
    } 
} 

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

Это дает вам модель, с которой вы можете перейти к различным представлениям View и PartialViews.

Последним шагом в вашем исходном посте является то, как получить это в представлении. Я играю с подходом ViewModel к этой проблеме. Создание ViewModels либо динамически, либо как класс, и висит все сущности в этой ViewModel. Недавний вопрос StackOverflow затрагивает эту концепцию. ViewModel Best Practices

Я передал модель непосредственно в представления, и теперь я пытаюсь использовать этот подход. Он очищает все, так как ваша модель DOmain действительно должна быть отключена от «логики» на вашей странице. Я думаю, что подумаю: «Пойди, мне нужно, чтобы этот частичный просмотр был заполнен на основе этого идентификатора. Предположим, это означает другой метод для сущности». Переход к подходу ViewModel удаляет логику/мышление из модели домена и помещает ее туда, где он принадлежит, - в слое Application/UI, где вы точно настраиваете свой просмотр/частичный просмотр.

Answer 3

Это хорошая идея, чтобы дать вид модель лица с точкой зрения вместо всей области лица, таким образом, сами по себе, обеспечивая мнение, только необходимые питания для работы на

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

- <Host>/Movies/Comedy 
- <Host>/Movies/Horror 

, который в своей очереди отображать фильмы, которые принадлежат к той или иной категории