Частичные представления MVC, модели и многое другое

Question

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

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

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

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

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

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

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

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

Спасибо за внимание! : -)

Answer 1

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

В строгой форме DDD я использовал бы ваш пример фильма в качестве совокупного корня (концепция DDD). Внутри Movie у вас была бы бизнес-логика (методы), которая получает категории и связанные сущности, непосредственно связанные с Movie (то есть Categories-this-movie-own-in). Предполагается, что список «категорий», который вы хотите отобразить, является списком категорий, в которых находится этот фильм.

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);
    }
}

Конечно, вы можете рассматривать Категории как Объект Значения (VO, концепция DDD), если у вас нет идентификатора.

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

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.

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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