Доменная модель сомневается

Question

С одной стороны, я хочу написать убийственное приложение (в ASP.NET MVC);) Но, с другой стороны, у меня много сомнений в том, что мне следует придерживаться так называемых «лучших практик» любой ценой. Итак, у меня вопрос о дизайне , и я очень надеюсь, что вы мне поможете.

Представьте себе стандартный блог. Я хочу показать 10 самых последних сообщений. Моя база данных имеет стандарт
Posts, Categories, Tags, PostTags
столы. Естественно, мой класс Post домена имеет такие свойства:

public Category Category { get; set; }
public virtual ICollection<Tag> Tags { get; set; }

Я использую EF4 с поддержкой POCO. И я загружаю данные стандартным запросом:

from p in context.Posts.Include("Category").Include("Tags")
select p

Но зачем мне загружать весь класс Post (например, с этими двумя свойствами), когда на странице все, что я хочу показать (кроме самого сообщения), это ссылки на категорию и каждый тег, поэтому все нужные мне столбцы являются:
[Categories].[Name], [Categories].[Slug], [Tags].[Name], [Tags.Slug].

Мне не нужен весь экземпляр Category или Tag (который может иметь 100 столбцов в соответствующей таблице в базе данных)! Я полагаю, что когда сайт получает много запросов, это имеет значение. Поэтому было бы неплохо не загружать все столбцы (избегайте страшных SELECT *).

Я думал, что смогу добавить новый класс в свой домен, скажем: ShortPost. Но я чувствую, что это не моя область! Post - это модель, ShortPost - это ... ну, просто часть полного сообщения. Кроме того - этот ShortPost кажется мне модификацией / настройкой Домена (Модели), чтобы угодить Представлению.

Подводя итог: Должен ли я действительно загружать весь экземпляр Model, когда на стороне просмотра мне не нужен весь объект? Не могли бы вы рассказать мне о некоторых предпочтительных решениях / способах / и т.д.?

Answer 1

Как насчет того, чтобы не использовать свои сущности для чтения?Это характеристика шаблона разделения команд и запросов.

Если единственные поля, необходимые для просмотра, - это [Категории]. [Имя], [Категории]. [Слаг], [Теги]. [Имя], [Тэги.Slug]

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

public class PostDto
{
    public string CategoryName { get; set; }

    public string CategorySlug { get; set; }

    public string TagName { get; set; }

    public string TagSlug { get; set; }

}

Answer 2

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

Было бы непонятно, если в кеше есть частично заполненные объекты.

Answer 3

Учитывая ваш пример - я бы сказал:

public class Post
{
    public Category Category {get;set;}
}
public class Tag
{
    public Post {get;set;}
}

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

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

И если вам в какой-то момент нужно показать статистику о вашем Посте (сколько тегов он прикрепил и т. Д.), Вы можете использовать «просмотры» изваши данные только с данными, которые вам нужны (эквивалентно просмотрам по таблицам в вашей БД).Просмотры находятся за пределами вашего домена, поэтому вам не нужно придерживаться правил вашего домена.Затем, когда вы входите в «режим редактирования», вы загружаете полную сущность.