Best Practices ASP.NET, в чём смысл многослойности?

Question

[Tsiren Naimanov]

Наткнулся на статью Solution Arch
Классно всё написано, но без тонкостей...
Зачем такая многослойность? Repository => Service
Почему всё решение на Github, разбито на проекты?
А конкретно, почему модели в отдельном проекте и service отделен?
Или это обусловлено разными слоями архитектуры?

Answer 1

[Толстый Лорри]

Сервис - это бизнес-логика, которая позволяет абстрагироваться от DAL с его репозиториями.

Слои:

• абстрагированы друг от друга - заменяемы (допустим, заменяя презентационный слой можно из обычного сайта сделать SPA или бэкенд для мобильного приложения; мы не зависим от модели хранения (разные СУБД, файлы, глиняные таблички, голубиная почта), можем легко "вклинить" какой-нибудь прокси-слой между ними, который будет проводить какую-либо обработку или кэшировать, например)
  
• абстрагированы друг от друга - их легко изучать, легко поддерживать (модифицировать, т.к. четко разграничена зона ответственности и меньше риск, что от взмаха крыла бабочки на другом конце света рухнет небоскреб)
  
• легко поддаются независимому тестированию (взяв один тип можно легко воспроизвести вокруг него необходимое тестовое окружение)
  

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

Comments

[Tsiren Naimanov]

А можете ещё на 1 вопрос ответить...
Вот например, сейчас не знаю как делать
Есть таблица Пост, у неё связь M2M к таблице Tag, тк тегов N может быть у неё, и собственно их множество
Куда вписывать метод поиска поста по тегу, в post service/respository или tag service/respository???
Или например, есть Пост таблица, в ней свойство - Категория
Куда выносить, поиск по названию категории, в category s/r или в посте?

[Tsiren Naimanov]

Я чую задал глупый вопрос, но всё равно надеюсь вы ответите :)

[Толстый Лорри]

Tsiren Naimanov: Наша цель - делать как можно меньше лишних запросов, т.е. одним запросом. Запросы у нас формирует репозиторий, потому его нужно научить так делать. В принципе, тут от задачи зависит, что решается на уровне BL (сервис) или DAL (репозиторий), т.к. логику можно в некотором объеме перемещать между слоями.

[Толстый Лорри]

Tsiren Naimanov: А в какой именно репозиторий - можно решить, отталкиваясь от сущности, которая является нашей целью: мы извлекаем что? Пост => BlogPostRepository.GetPostsByTag(Tag t). Когда нам нужно загрузить список из тегов для облака тегов, то мы дергаем TagRepository.

[Tsiren Naimanov]

Толстый Лорри: то есть, можно даж написать некое подобие правила
Дергать в репозитории то, что является аттрибутом в нём
очень грубо говоря
кстати насчёт EF, запросы при выборке, например where не исполняются же до конца, пока не будет объявлено .ToList() ??? или это я не правильно понял насчёт IEnumerable?

[Толстый Лорри]

Tsiren Naimanov: Представьте, что репозиторий это полка с %TableName%.

По поводу EF, это свойство LINQ и его IQueryble интерфейса. Методы, возвращающие IQueryable достраивают ваш запрос (expression tree), а те, что возвращают разного рода IEnumerable - выполняют/посылают его. Справедливо как для EF, так и, скажем, для List (Linq2Entitites).

[Tsiren Naimanov]

var builder = new ContainerBuilder();
            builder.RegisterControllers(Assembly.GetExecutingAssembly());
            builder.RegisterType<UnitOfWork>().As<IUnitOfWork>().InstancePerRequest();
            builder.RegisterType<DbFactory>().As<IDbFactory>().InstancePerRequest();
 
            // Repositories
            builder.RegisterAssemblyTypes(typeof(GadgetRepository).Assembly)
                .Where(t => t.Name.EndsWith("Repository"))
                .AsImplementedInterfaces().InstancePerRequest();
            // Services
            builder.RegisterAssemblyTypes(typeof(GadgetService).Assembly)
               .Where(t => t.Name.EndsWith("Service"))
               .AsImplementedInterfaces().InstancePerRequest();
 
            IContainer container = builder.Build();
            DependencyResolver.SetResolver(new AutofacDependencyResolver(container));

Можете объяснить код?))0 интересует только где отмечено services/respo...
где идет where и asImplementedInterfaces()

[Толстый Лорри]

Tsiren Naimanov: IoC-контейнер исследует сборку (ту, в которой лежит GadgetRepository) в поисках классов, заканчивающихся на "...Repository" и автоматически регистрирует их в качестве внедряемых зависимостей для интерфейсов, которые они реализуют. Будет внедрять одну сущность на запрос.

[Tsiren Naimanov]

Толстый Лорри: значит, у меня 10 репозиториев и 10 сервисов, надо написать только по 1 регистрации?

[Толстый Лорри]

Tsiren Naimanov: все зависит от задачи. Вы понимаете смысл внедрения зависимостей?

[Tsiren Naimanov]

Толстый Лорри: слабо понимаю, но хочу на практике добить...
плюс попутно читаю https://habrahabr.ru/post/62830/

[Tsiren Naimanov]

Толстый Лорри: то есть получается, внедрение зависимостей, является упрощение вызова/создания объекта, тем что некая фабрика сама будет это осуществлять, при необходимости и не будет нужды, заботиться о создании этих объектов самому

[Толстый Лорри]

Tsiren Naimanov: Прикладной пример: нужные для контроллера интерфейсы сервисов объявляются как аргументы конструктора, а фабрика контроллеров (с помощью IoC-контейнера) позаботится о том, чтобы под требуемые интерфейсы подобрались нужные имплементации. А в коде выше мы конфигурируем связь "интерфейс <--> реализация"