Трехтировое (трехслойное) приложение
HTML-код
- Опубликовано: 26 янв 2025
- Продолжаем обсуждение декомпозиции. В этот раз я остановился на очень важной концепции - трехуровневом (трехзвеном, трехлеерном) приложении
Полный плейлист: • Основы архитектуры при...
Благодарю за видео, Сергей. Вас приятно слушать - у вас приятный голос и смотреть, поскольку видно, что вы получаете от этого удовольствие. Успехов вам!
***** любите рок - это хорошо. У вас есть аудиозаписи музыки, которую играла ваша группа, аудиозаставка ваших рук дело?
Смотрю вам по рекомендации своего джава-ментора. Спасибо огромное!
Привет из 2020 г . Спасибо за это видео
Очень хорошее объяснение. Большое спасибо!
Дякую тобi Сергій. Дуже цікаво...
То есть в такой архитектуре нет места для хранимых процедур БД? (ну если конечно не вся бизнес логика на PL/SQL описана)
А вообще хотелось бы узнать ваше мнение по поводу расположения бизнес логики в приложениях активно работающих с БД
розкажіть в якомусь із наступних відео про TDD в ентерпайзі та взагалі
Спасибо, прилетела более менее крупная задачка, смотрю и учусь.
CRUD это не retrieve, a read)
Сейчас всё прекрасно слышно. В прошлых видео были проблемы со звуком при записи экрана, наверное это было шумоподавление.
12:00 что-то не понял: так минуя бизнес-логику, напрямую, или нет?
Класс! Спасибо, очень интересно! :-)
***** Спасибо за ваш труд! Продолжайте в том же духе :-)
***** :-)
Спасибо за видео, Сергей! Вопрос - а разве эта "Трехтировая архитектура", не есть чистокровное MVC?
@@FreemanFromSteppe MVC - это Model-View-Controller. Очень понятно объяснено здесь: ruclips.net/video/Z9dvZyEofAg/видео.html
Спасибо
Покороче и почаще это верно по всей видимости :)
Прекрасно объясняет
Если правильно понял, то "бизнес-логика" должна размещаться в контроллере, но, например в статье про MVC, на Википедии ( ru.wikipedia.org/wiki/Model-View-Controller#Наиболее_частые_ошибки ), указано, что - это ошибочно и ее следует размещать в "модели". В MVP - бизнес-логика - в Presenter ( ru.wikipedia.org/wiki/Model-View-Presenter ).
Где же размещать "бизнес логику" и почему?
Я джун, поэтому к моему ответу отнеситесь критически, если я сказал чушь - пусть опытные товарищи подскажут, где я неправ. MVC - это архитектурный паттерн, который отвечает за взаимодействие бизнес логики и пользовательского интерфейса. И он является надстройкой над трёхслойной моделью. View и Controller относится к UI, а всё остальное к Model. Задача View состоит в представлении интерфейса для пользователя, будь то отрисовка со всякими анимациями или что-то ещё. Больше она ничем не занимается. Контроллер же отвечает за взаимодействие пользователя с бизнес-логикой. Никогда не использовал MVC, так что я могу быть не прав. В MVP бизнес логика не находится в презентере, он отвечает за представление, и в нём находится только логика непосредственно интерфейса, он управляет VIew, туда приходит пользовательский ввод, он же обеспечивает взаимодействие с Model. Допустим ваше приложение считает сколько калорий вы получили, сколько потратили, следит за здоровьем и всё в таком духе. Убрали View Controller или View Presenter, перешли например на MVVM, переписали под другой фреймворк, дизайнер сделал полностью новый дизайн. Бизнес логика не изменилась. Приложение по-прежнему считает калории и следит за вашим здоровьем. Данные точно так же сохраняются в бд и загружаются на облако. Надеюсь понятно всё объяснил и нигде не ошибся.
Хотя мне кажется, Сергей уже ответил на этот вопрос в своём видео, но я этого не видел.
Внезапный переход с процедурного видео на обьектно-ориентированное :D
Видео хоть и не новое, но я как-то не понял откуда взялась новая интерпретация для CRUD? (где-то с 10й минуты видео)
Wiki об этом использует другие слова.
Сокр. от англ.: Create, Read, Update, Delete - т.е. «создать, прочесть, обновить, удалить».
Или это что-то новенькое у тебя?
Привет 2021.
MVC выросло из этой же концепции? Или это она и есть? Или MVC существовала и в 2015, а три уровня - это про другое?
мвс появилось в 79 году. трехслойная архитектура появилась позже.
Помимо зачетного содержания видео, хотел бы отдельно лайкнуть музыкальное оформление. Бодрит..
У меня появился такой вопрос - а как собственно реализуется в коде взаимодействие этих слоёв? Тоесть банально используются геттеры и сеттеры или же всё таки как-то иначе?
Обычно элементы этого приложения разнесены физически. А значит их связь происходит через какой нибудь Rest API
Добрый день, расскажите пожалуйста, про архитектуру приложения расширяемого плагинами. Есть ли тонкости?
эм. что именно рассказать? У меня есть тренинг про энтерпрайз паттерны, там немного дофига материала. Вот он: foxminded.com.ua/enterprise-patterns-advanced-course/
@@SergeyNemchinskiy Уточню вопрос. Есть клиентское приложение, функционал которого расширяется плагинами. Стоит ли в один плагин включать все три слоя: данные/логика/гуй, а основное приложение просто сервис для отображения гуев от плагинов+работа с запросами к серверу. Или стоит работать в другой конфигурации?
Классные видео. Еще бы микрофон выносной был, вообще бы было замечательно :)
***** Думаю здесь замечание не на громкость звука, а на качество :-)
***** Слышно, но копеечная петличка сделает качество звука намного лучше.
Спасибо за видео такие байки для меня очень актуальны!
У меня вопрос про JPA (Java Pesistence API).
Считаете ли вы JPA слоем DAO? Если нет не могли бы вы пояснить почему.
Я пришел к выводу что таки ДА JPA это оно самое DAO и есть. И вот как я к этому мнению пришел.
Постигаю Java опытом.=) Пишу небольшой проект интернет магазина. Взял Servlet API и JPA. Решил начать работу с DAO слоя. DAO объектах стал писать логику JPA запросов и в итоге понял что мои DAO будут пополнятся методами определяющими конкретные запросы что отдает неприятным душком.) Решил отрефакторить) из чего стала получатся какая-то обертка над JPA и Creteria API что тоже отдает не очень.) В итоге пришел к выводу что JPA и есть DAO слой а логику запросов стоит вынести в бизнес сущности манипулирующие коллекциями объектов.
Сергей Кондратьев а разве JPA не есть частный случай (на уровне языка) реализации DAO концепции? Кстати, а почему вы начали с DAO слоя, а не со слоя Domain? Ведь в именно в нём реализуется все бизнес процессы, а DAO и UI слои отвечают за "техническую поддержку" (фактически работу) самой бизнес логики реализованной как раз в Domain слое.
Похоже так и есть. Меня смущало то что в JPA нужно конструировать запрос как SQL. Мне казалось DAO должно состоять из методов получающих параметры для запросов и возвращающих бизнес сущности. В итоге JPA стал вторым SQL. А когда я попытался сделать DAO гибче получилась какая-то обертка над JPA. Цель проекта получить опыт использования различных API как в данной итерации это Servlet API и JPA.
14:21 -☝
Насколько я знаю, трёхуровневая архитектура описывает несколько(!) приложений, разнесённых физически и взаимодействующих по сети (см. хотя бы Википедию). А вы здесь описываете шаблон построения одного(!) приложения. Т.е., по сути, под ваше описание скорее подходит какой-нибудь MVP.
Можеш розказати про потоки, асинхронність і взаємодію між рівнями 3-рівневої архітектури?
***** ну ти ж професіонал і тому, я прошу в тебе щоб ти якраз розказав про всю цю жесть, з точки зору досвідчиного дева, бо в "ентерпрайзі" це досить часто зустрічається.
значить тобі більше везе))
Знаменитый "китаец" Yong Mook Kim кореец
CRUD - Create Read Update Delete
Кто дислайк влепил? А ну по айпи его вычислять и адрес мне... :)
***** ага. Иван Головач ставит дислайки, скорее всего. :)))