Отображения базы данных Onion Architecture - PullRequest
Новая
       43

Отображения базы данных Onion Architecture

0 голосов
/ 06 марта 2020

Я играл с Луковая архитектура , DDD и Шаблон спецификации . Существует множество реализаций с Entity Framework, , где сущности домена идут прямо в DBSet <> контекста . Для меня это не нормально, по крайней мере, из-за отношений «многие ко многим». Допустим, у нас есть следующие dbo: 


    public class Post
    {
        public int PostId { get; set; }
        public string Title { get; set; }
        public string Content { get; set; }

        public List<PostTag> PostTags { get; set; }
    }

    public class Tag
    {
        public string TagId { get; set; }

        public string Name { get; set; }

        public List<PostTag> PostTags { get; set; }
    }

    public class PostTag
    {
        public int PostId { get; set; }
        public Post Post { get; set; }

        public string TagId { get; set; }
        public Tag Tag { get; set; }
    }

Проблема в том, что модели сущностей не должны ничего знать о Post.PostTag, потому что это подробности реализации персистентного слоя. Например, я могу изменить хранилище на JSON объектов, и больше не требуется промежуточная таблица. Итак, в идеале, мои модели сущностей будут выглядеть так: 

    public class Post
    {
        public int PostId { get; set; }
        public string Title { get; set; }
        public string Content { get; set; }

        public List<Tag> Tags { get; set; }
    }

    public class Tag
    {
        public string TagId { get; set; }

        public string Name { get; set; }
    }

Или это будет еще хуже, если мы решим добавить какое-то новое свойство к PostTag, например 


    public class PostTag
    {
        ...
        public bool IsActive { get; set; }
        ...
    }

Тогда это повлияет на Tag при рассмотрении этого примера с моделью сущности. 

public class Post
    {
        public int PostId { get; set; }
        public string Title { get; set; }
        public string Content { get; set; }

        public List<Tag> Tags { get; set; }
    }

    public class Tag
    {
        public string TagId { get; set; }
        public bool IsActive { get; set; } // this is added
        public string Name { get; set; }
    }

Из-за этого я хочу, чтобы и entity и dbo моделей. Когда я реализую PostRepository, который расположен на уровне инфраструктуры, и я хочу выставить IQueriable<Post> Query(). Вот настоящие проблемы начались. Причина проблем заключается в том, что прикладной уровень, являющийся потребителем репозитория, может работать только внутри объекта Post, но не PostDbo. И они могут быть разными. Из-за этого я не могу написать спецификацию для этой сущности. Итак, главный вопрос заключается в том, как реализовать шаблон Repository, который может предоставлять такой метод Query(), при этом отдельные модели entity и dbo не оказывают серьезного влияния на производительность и оптимальность запросов.

Или, может быть, шаблон спецификации - это просто огромные накладные расходы, которые более вредны, чем полезны. Причина в том, что когда вы решаете изменить структуру сущностей на что-то другое, вам следует написать свой собственный поставщик запросов для Expression<Func<TEntity>>. Как вы думаете?

Может быть, я что-то не так, поправьте меня, пожалуйста. Буду благодарен за разумные ответы.

Спасибо

...