C# Архитектура приложения | Трёхзвенная(трёхуровневая) архитектура

[@k1ntoho]

Охренительный ролик, как раз то, что искал! Спасибо большое

[@nursultanmamytbekov8180]

Спасибо за лекцию! Очень информативно и понятно. Жду продолжения!

[@Keeytari]

Спасибо большое за ваш урок! Очень понравился! Пожалуйста, не останавливайтесь и продолжайте выпускать видео по C#, у вас очень хорошо получается!

[@AlexCSharp]

Спасибо! Я планирую)

[@Keeytari]

@@AlexCSharp Кстати, делай репозитории на GitHub для каждого урока, это очень полезно. Есть канал CodeBlog тоже учит C#'пу (Немного о нем: Зовут Вадим, 8 лет уже работает на шарпе) и вот он делает на каждый урок свой репозиторий. Просто когда я делаю программы, я частенько залажу на его определенный репозиторий и смотрю как у него что-то реализованно.

[@AlexCSharp]

@@Keeytari Я его знаю, но это был урок для школы программистов вообще.) Я не планировал канал вести, но будет видно) Думаю сюда просто разборы архитектур учеников ещё выкладывать, и занятия не по чистому языку(их как грязи) а по архитектурам, практикам в коммерческой разработке, SOLID и т.п. Но язык будет C# и технологии его же.

[@Keeytari]

@@AlexCSharp Я новичок в C#, чуть больше года занимаюсь им. Мне как раз таки архитектура приложений нужна) Так как я сейчас разрабатываю прогу, сделал много функционала и все пойдет коту под хвост, так как все выглядит как какое-то дерьмо) Мне нужно научиться как раз таки делать архитектуру приложения правильно, чтобы все было удобно и понятно.) Спасибо за урок еще раз! И не забрасывайте канал, у вас хорошо получается, я думаю, что многим ваш опыт и видео будут полезны!

[@Keeytari]

@@AlexCSharp С вами солидарен) Просто роликов по самому шарпу много, а вот по архитектурам мало, а еще меньше тех, которые рассказывают о коммерческой разработке, как все строится, как выглядит архитектура приложения и тд тп. Все что связано с коммерческой разработкой, этого всего мало) А роликов по типу: Изучаем паттерн Одиночка много)

[@АлисаЛис-л3б]

Хочу еще Ваши уроки по C#!!!!!!!!!!!! Лучшее объяснение что когда либо слышала!!!!!

[@AlexCSharp]

Я планирую записать ещё. Как будет время. )

[@jocker4396]

@@AlexCSharp Жду новые уроки, отличная лекция

[@АлисаЛис-л3б]

Лучшее по архитектуре! Спасибо!!!!

[@AlexCSharp]

Прошу прощения за плавающий звук, буду фиксить)

[@shkurmander]

А не вы писали скринкасты для SkillFactory для курса Разработчик C#, в частности по разработке проекта SocialNetwork?

[@AlexCSharp]

@@shkurmander нет, мне не нравятся системы большинства школ программирования, поэтому я если что-то и делаю, то для их учеников, а не самих школ. ) Если встретили что-то похожее -не удивительно, ведь я учу best practices, а best они не просто так, и довольно распространены. Да и первоисточники я указал в начале ролика, можете ознакомиться, найдёте параллели наверняка. ;)

[@destroyergame8131]

топ все очень просто и понятно рассказываешь)

[@kayobjerg7057]

Pure gold!! Шикарно!

[@kayobjerg7057]

Больше бы :/

[@danieln446]

Спасибо! Не останавливайся!

[@abtoputet777]

Очень понятно, спасибо за труд!

[@bpht618]

Отличное видео, подпишусь, вдруг автор решит продолжить)

[@xilalix]

Мощное видео

[@alexeyklochkov2275]

Отлично, спасибо!

[@sehrgutlocj]

Это архитектора контроллер сервис репозиторий?

[@СоломонЗуев-я2л]

Спасибо за видео

[@kurnakovv]

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

[@AlexCSharp]

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

[@kurnakovv]

@@AlexCSharp Спасибо за ответ! Вроде понятно. Еще вопросик, декораторы можно ли перегружать? Ну то есть добавить не только логику логирования, но и другой функционал или же декоратор нужен только для точной функциональности? (только логирование и больше нельзя если надо еще создавайте еще 1 декоратор)

[@AlexCSharp]

@@kurnakovv Строится цепочка декораторов. Чем больше разнопланового кода в одном месте - тем тяжелее читать, тем тяжелее дебажить. Каждый класс должен быть сфокусирован на одной задаче, как говорит Макконнелл. Это касается не только декораторов.

[@kurnakovv]

@@AlexCSharp Ок, еще раз спасибо! Жаль что вы больше видео не выпускаете...

[@AlexCSharp]

@@kurnakovv Много других дел. Надо работать, развиваться самому, писать методички для всё подрастающих учеников, поэтому на видео пока времени нет. Хотя хочу выпустить более крутые и проработанные видео по архитектуре, есть сценарий, но сложно все крутые штуки хорошо проработать и совместить, требует прорву времени.

[@Евгений-т3ъ3п]

Отличный контент, Алекс, спасибо! Оставь пожалуйста свои координаты для связи, хотелось бы взять у тебя несколько уроков, в Телеге не смог найти тебя

[@AlexCSharp]

Спасибо! t.me/RenMaRus может быть так выйдет

[@orhanaliyev9774]

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

[@AlexCSharp]

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

[@ДмитроМартинов-о8з]

Спасибо!)

[@maksim3281]

Мне кажется, что у класса DriverEntity должно быть поле со списком машин, иначе как нам подгружать связанные данные? Например, информацию о водителе и его машинах? Делать несколько запросов к бд? Для примера возьмем такой случай: нам нужно получить водителей, чей возраст находится в диапазоне от age1 до age2 и получить информацию о их машинах (для какой-нибудь статистики).

[@AlexCSharp]

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

[@maksim3281]

А для чего в слое Entities нужен интерфейс IBaseEntity и абстрактный класс BaseEntity. Можно ли отказаться от интерфейса? Просто не до конца понятно в чем преимущество этого интерфейса, если абстрактный класс, ничего более не привносит. Может просто оставить абстрактный класс и всё?

[@AlexCSharp]

Можно отказаться и от того, и от другого. Всё зависит от задачи.

[@ИгорьКочат]

Планируешь ещё пилить видео по c# ?

[@AlexCSharp]

Давно планирую, но всё никак не запилю. А скоро ещё начнут запрещать образовательную деятельность без аккредитации и всё, приплыли. )

[@ИгорьКочат]

@@AlexCSharp Сейчас не так много толковой информации по шарпам на ютубе. Будет очень круто, если продолжишь это дело

[@AlexCSharp]

@@ИгорьКочат по шарпам-то как раз предостаточно. А вот по архитектуре и кодстайлу мало. И я не столько шарпы даю(это просто язык, на котором я работаю), сколько общие принципы построения систем. Они подойдут для любого ООП-языка.

[@ИгорьКочат]

@@AlexCSharp Можно у тебя взять урок по архитектуре ?

[@AlexCSharp]

@@ИгорьКочат Конечно, под видео моя тг.

[@ВладиславШумейко-ф3з]

без dependency injection?

[@AlexCSharp]

В смысле без IoC? это не относится к архитектуре, каждый сам решает, как именно управлять созданием объектов и их циклом жизни.

[@nikitashevyakov3057]

Спасибо за лекцию! Все круто! Есть вопрос, надеюсь, если не ответите то хоть на толкнете на мысль. А как бы вы реализовывали структуру, если проект, а точнее сервисы разросстаются до большиъ масштабов? Получается, что не сильно удобно становится использовать сервисы, в плане бегать по сервису и искать нужный метод. Можно ли как-то от этого уйти? Заранее благодарю

[@AlexCSharp]

Сервис работает с одной сущностью. Если у Вас 1000 и 1 метод для работы с одной сущностью: можно перейти на CQRS. Но тогда будет 1000 и 1 класс. А если эти методы не касаются непосредственно CRUD-функционала - их стоит вытащить в отдельные типы, в зависимости от смысла: конвертеры, мапперы, сериализаторы, дескрипторы и т.п. Опять же, используйте инструменты для обобщения и универсальности. Например, если надо получать одну и ту же сущность по 3м разным параметрам - не надо писать 3 разных метода, достаточно 1го метода, принимающего делегат с условием, где на более высоком уровне уже будет приниматься решение, по какому условию сущность будет получена.

[@nikitashevyakov3057]

@@AlexCSharp Спасибо за ответ! Только у меня небольшой диссонанс появился. Получается работать в сервисах мы можем/должны в рамках 4 методов (добавления, обновления, получения, удаления)? Напрашивается вывод, что для сложного приложения (с запутанной логикой) такое не подходит... В сложном приложении получение(редактирование, удаление, добавление) одной сущности может осуществляться разными способами. К примеру: 1) получение данных для пользователей разного уровня доступа. Руководитель (который видит всю инфу) и рядовой сотрудник (только то что ему нужно). В каком слое нужно отсеивать "лишнее" для рядового сотрудника и "оставить" для руководителя? 2) тоже самое хотелось бы спроецировать и на редактирование, к примеру некоторые данные рядовой сотрудник имеет право редактировать, а некоторые нет. Понятно, что можно ограничить ввод данных на UI слое, но хотелось бы услышать где правильнее это делать на стороне сервера. Буду признателен за ответ!

[@AlexCSharp]

@@nikitashevyakov3057 Отсеивать лишнее в сервисном слое. На UI лететь должно только то, что необходимо. CRUD- это не 4 метода, это 4 типа операций. Удаление может быть разное, хардделит, софтделит, делит по условию и т.п., так же с получением данных: 1 сущность, коллекция, по такому условию, по эдакому условию, это всё CRUD. Но репозиторий не должно волновать, у кого там какие пермишены и т.п., максимум, это регулируется, как я выше писал, условием через делегат в качестве параметра. Get(Func condition). А про то, кто там что может редактировать - это решается на уровне UI, а если при недостаточном пермишене приходит запрос от UI на редактирование того, чего нельзя- ошибку кидать уже из контроллера. Репозиторий за такие вещи вообще не должен отвечать.

[@nikitashevyakov3057]

@@AlexCSharp Благодарю вас!

[@eriator3359]

+++++

[@husentochiev5067]

Слишком много повторяющегося кода. Меня это немного напрягает :)

[@AlexCSharp]

Таковы правила игры. Претензии к создателям слоистых архитектур. Главное, при устройстве на работу никому этого не говори.

[@lonelypaul69]

а где ApplicationContext???

[@AlexCSharp]

Чтобы что? Это на откуп тех, кто пишет приложение. Я описывал бизнес-составляющую.

[@lonelypaul69]

@@AlexCSharp понял