Здравствуйте, es3000, Вы писали:
E>А если используется асинхронное взаимодействие верхнего и нижнего уровней? E>Верхний уровень отправил сообщение. E>Как верхний уровень потом получит ответ от нижнего уровня?
Через очередь сообщений. Поставил в очередь задание, через некоторое время проверил статус, приспичило отменил задание.
Здравствуйте, es3000, Вы писали:
E>Здравствуйте, samius, Вы писали: S>>Да, у Мартина так. Но есть примеры других архитектур, где не так. S>>https://www.oreilly.com/library/view/software-architecture-patterns/9781491971437/ch01.html S>>https://en.wikipedia.org/wiki/Multitier_architecture#Common_layers
E>Суть та же самая: сделать код одного слоя независимым от других слоев. E>Причем это даже не архитектура, а общие формулировки.
Верно. Сначала делали независимыми функции, потом объекты, далее слои. Идея та же, масштаб растет. Но нового ничего.
S>>У Мартина зависимость BLL от DAL инвертирована, BLL не видит DAL напрямую, вместо этого обращается к Repositories. При этом BLL все еще может формировать критерии для выборки, т.е. управлять инструкциями, которые выполняет DAL.
S>>У Мартина, но не вообще.
E>Просто подход Мартина — внес новую идею в разделение слоев.
Спрятать БЛ за репозиторием и нарисовать во внешнем слое на диаграмме? E>За счет этого это разделение слоев стало еще лучше.
Можно конкретнее?
E>Ну это как постепенное развитие например бензиновых двигателей. E>Ясное дело, что современные двигатели во много превосходят двигатели 50-летней давности. E>Так и подход к разделению слоев. E>Подход Мартина — более конкретен чем предыдущие общие формулировки.
Более конкретен чем?
Если БЛ у нас управляет тем, какие Entity ему нужны, какая разница, где мы нарисовали DAL, во внешнем слое, или во внутреннем? Линейно расположили слои, или луковицей?
S>Аргументация на что? Ты послал меня книжки полистать и найти там тезисы. Им оппонировать?
Нет, не книжкам оппонировать.
А аргументировать свои тезисы.
Мы сильно в "философию" углубились.
Предлагаю "откатиться назад" и вспомнить первые вопросы:
Бывает ли такое, что бизнес-слой должен управлять поведением (логикой) другого слоя приложения?
Если ответ положительный и так делается, то как реализуется такое управление?
Как сделать внешний слой, о котором по сути Бизнес-логика ничего не знает, управляемым?
Еще раз, скажи пожалуйста, свои тезисы в ответ на эти вопросы.
Только я уточню, что речь идет не о нижележащих слоях, которыми управляют через их интерфейсы.
А речь идет об управлении вышестоящим слоем, который как бы неизвестен.
Насколько я понимаю, единственный способ общения нижестоящего слоя с вышестоящим — это через механизм событий-подписок.
Например, Слой приложения (вышестоящий) использует Бизнес-слой.
Слой приложения отправляет команды Бизнес-слою через интерфейс, а в ответ получает какие-то события.
Надо, чтобы Бизнес-слой как-то повлиял на логику Слоя приложения.
E>>А если используется асинхронное взаимодействие верхнего и нижнего уровней? E>>Верхний уровень отправил сообщение. E>>Как верхний уровень потом получит ответ от нижнего уровня? _>Через очередь сообщений. Поставил в очередь задание, через некоторое время проверил статус, приспичило отменил задание.
Если так все просто, почему через очередь сообщений не может общаться верхний уровень с нижним?
А можно ведь сделать, что все друг с другом будут общаются через очередь сообщений.
Полная независимость. Красота.
E>>Просто подход Мартина — внес новую идею в разделение слоев. S>Спрятать БЛ за репозиторием и нарисовать во внешнем слое на диаграмме?
Да.
E>>За счет этого это разделение слоев стало еще лучше. S>Можно конкретнее?
Ну раньше ломали голову: как отделить БЛ от хранения данных.
А теперь Мартин предложил удобное решение.
E>>Подход Мартина — более конкретен чем предыдущие общие формулировки. S>Более конкретен чем?
Тем, что предложил удобное архитектурное решение.
S>Если БЛ у нас управляет тем, какие Entity ему нужны, какая разница, где мы нарисовали DAL, во внешнем слое, или во внутреннем? Линейно расположили слои, или луковицей?
Не знаю какая разница. Может быть и никакой.
А что ты сказать-то хочешь?
А то всё задаешь вопросы. Ты мысль свою вырази.
E>>Как сделать внешний слой, о котором по сути Бизнес-логика ничего не знает, управляемым?
V>Через абстракции — добавить интерфейс, который внешний слой должен реализовывать. Или же генерировать события, на которые внешний слой подпишется.
Тогда получается, что оба слоя и внешний и внутренний ничем друг от друга не отличаются:
— и внутренний слой предоставляет свои интерфейсы для управления им извне
— и внешний слой предоставляет свои интерфейсы для управления им извне.
— оба слоя вызывают подписчики событий в ответ
Тут уже и нельзя сказать: какой из них внутренний, а какой внешний.
Они оба получились на одном уровне.
Здравствуйте, es3000, Вы писали:
E>Предлагаю "откатиться назад" и вспомнить первые вопросы: E>
E>Бывает ли такое, что бизнес-слой должен управлять поведением (логикой) другого слоя приложения?
E>Если ответ положительный и так делается, то как реализуется такое управление?
E>Как сделать внешний слой, о котором по сути Бизнес-логика ничего не знает, управляемым?
E>Еще раз, скажи пожалуйста, свои тезисы в ответ на эти вопросы.
1. Да, бывает. Вообще обычно бизнес-слой всем и управляет. Пример: пришла почта, нужно показать уведомление в UI. Кто инициатор? Логично что бизнес-слой.
2. Что как? В чем проблема заключается? Я не понимаю, на что отвечать. События, интерфейсы, что по сути одно и то же. События — интерфейсы для бедных. Интерфейсы — события для бедных.
3. См. 2.
E>Только я уточню, что речь идет не о нижележащих слоях, которыми управляют через их интерфейсы. E>А речь идет об управлении вышестоящим слоем, который как бы неизвестен.
Аналогично. E>Насколько я понимаю, единственный способ общения нижестоящего слоя с вышестоящим — это через механизм событий-подписок.
Что значит, единственный? БЛ может выставлять флаг/команду, а UI его проверять в каждом оконном сообщении. Суть-то не меняется.
E>Например, Слой приложения (вышестоящий) использует Бизнес-слой. E>Слой приложения отправляет команды Бизнес-слою через интерфейс, а в ответ получает какие-то события. E>Надо, чтобы Бизнес-слой как-то повлиял на логику Слоя приложения.
Бизнес-слой тоже может отправлять команды.
Здравствуйте, es3000, Вы писали:
E>>>Просто подход Мартина — внес новую идею в разделение слоев. S>>Спрятать БЛ за репозиторием и нарисовать во внешнем слое на диаграмме?
E>Да.
Это не нововведение Мартина
E>>>За счет этого это разделение слоев стало еще лучше. S>>Можно конкретнее?
E>Ну раньше ломали голову: как отделить БЛ от хранения данных. E>А теперь Мартин предложил удобное решение.
Барьеры абстракций известны много лет (десятков лет). Их использовали даже в LISP. Кому надо было что-то отделить, отделяли.
Чего там ломать голову? Над чем?
E>>>Подход Мартина — более конкретен чем предыдущие общие формулировки. S>>Более конкретен чем?
E>Тем, что предложил удобное архитектурное решение.
Мне удобнее отделять в тот момент, когда это стало нужно. В каком месте на диаграмме слоев что нарисовано — дело десятое.
S>>Если БЛ у нас управляет тем, какие Entity ему нужны, какая разница, где мы нарисовали DAL, во внешнем слое, или во внутреннем? Линейно расположили слои, или луковицей?
E>Не знаю какая разница. Может быть и никакой. E>А что ты сказать-то хочешь? E>А то всё задаешь вопросы. Ты мысль свою вырази.
Я пытаюсь выяснить, чем лучше архитектура, предложенная Мартином? Но конкретно, а не просто "удобнее". Удобнее чем что? Удобнее чем? Для какого типа приложений?
S>1. Да, бывает. Вообще обычно бизнес-слой всем и управляет. Пример: пришла почта, нужно показать уведомление в UI. Кто инициатор? Логично что бизнес-слой.
А если подробнее — какой "сценарий"?
Что бизнес-слой передает в UI?
Просто сообщение "пришла почта"? Или команду "покажи уведомление"?
S>События, интерфейсы, что по сути одно и то же. События — интерфейсы для бедных. Интерфейсы — события для бедных.
А что есть для "богатых"?
S>Бизнес-слой тоже может отправлять команды.
Если два слоя отправляют друг другу команды, тогда они оба связаны друг с другом.
Они оба "равноправные", нету ни "вышестоящего" ни "нижележащего".
S>>1. Да, бывает. Вообще обычно бизнес-слой всем и управляет. Пример: пришла почта, нужно показать уведомление в UI. Кто инициатор? Логично что бизнес-слой.
E>А если подробнее — какой "сценарий"? E>Что бизнес-слой передает в UI? E>Просто сообщение "пришла почта"? Или команду "покажи уведомление"?
Я пример просто выдумал. Что бы ответить на эти вопросы, мне придется выдумать ответы. Но есть ли в этом какой-то смысл? Принципиальна ли разница между сообщением и командой?
S>>События, интерфейсы, что по сути одно и то же. События — интерфейсы для бедных. Интерфейсы — события для бедных.
E>А что есть для "богатых"?
Теория категорий и монады
S>>Бизнес-слой тоже может отправлять команды.
E>Если два слоя отправляют друг другу команды, тогда они оба связаны друг с другом. E>Они оба "равноправные", нету ни "вышестоящего" ни "нижележащего".
А если они отправляют команды не друг другу, а на деревню дедушке?
S>Это не нововведение Мартина
S>Барьеры абстракций известны много лет (десятков лет). Их использовали даже в LISP. Кому надо было что-то отделить, отделяли.
S>Мне удобнее отделять в тот момент, когда это стало нужно.
Ну вот как раз мне стало "нужно" отделять.
Поэтому я и задал вопрос.
Нужно разделить два слоя: Бизнес-слой внутренний, его использует внешний слой.
Я их разделил.
И теперь стало "нужно", чтобы внутренний слой повлиял на поведение внешнего.
S>В каком месте на диаграмме слоев что нарисовано — дело десятое.
В принципе я согласен.
Но что ты предлагаешь то?
Делать как попало? Не придерживаясь никаких принципов?
S>Я пытаюсь выяснить, чем лучше архитектура, предложенная Мартином? Но конкретно, а не просто "удобнее". Удобнее чем что? Удобнее чем? Для какого типа приложений?
А зачем это выяснять?
Ты все время пытаешься разговор куда-то в сторону увести.
Ну какая разница какая архитектура лучше или хуже?
Я уверен, что ты и сам понимаешь почему и зачем придуманы архитектуры.
E>>А если подробнее — какой "сценарий"? E>>Что бизнес-слой передает в UI? E>>Просто сообщение "пришла почта"? Или команду "покажи уведомление"? S>Я пример просто выдумал. Что бы ответить на эти вопросы, мне придется выдумать ответы. Но есть ли в этом какой-то смысл?
Я думаю, что смысл есть.
А то странно получается: какие-то философские вопросы мы обсуждаем, а как только дело дошло до конкретного решения — "нет смысла"?
Как будто ты избегаешь предложить конкретное решение.
S>Принципиальна ли разница между сообщением и командой?
По моему мнению, с технической точки зрения — разницы нету.
А вот с точки зрения назначения — есть.
А твое мнение? И как эта разница влияет на решение?
E>>А что есть для "богатых"? S>Теория категорий и монады
Когда-то пытался читать теорию категорий. Не понял ее практической применимости в программировании.
Про монады не слышал, сейчас почитаю.
Как теория категорий и монады могут помочь в озвученном вопросе?
E>>Если два слоя отправляют друг другу команды, тогда они оба связаны друг с другом. E>>Они оба "равноправные", нету ни "вышестоящего" ни "нижележащего". S>А если они отправляют команды не друг другу, а на деревню дедушке?
Опять одни вопросы. Ты кому вопросы задаешь? Тоже наверно на деревню дедушке?
Что сказать то хочешь? Ты как будто стесняешься.
Говори прямо — не стесняйся.
Мне любое мнение интересно.
Здравствуйте, es3000, Вы писали:
E>Ну вот как раз мне стало "нужно" отделять. E>Поэтому я и задал вопрос. E>Нужно разделить два слоя: Бизнес-слой внутренний, его использует внешний слой. E>Я их разделил. E>И теперь стало "нужно", чтобы внутренний слой повлиял на поведение внешнего.
О, как... (1)
S>>В каком месте на диаграмме слоев что нарисовано — дело десятое.
E>В принципе я согласен. E>Но что ты предлагаешь то? E>Делать как попало? Не придерживаясь никаких принципов?
До этого момента было обсуждение вопроса о том, "бывает ли такое". Никаких предложений не требовалось до сообщения, на которое я отвечаю. Я даже и подумать не мог, что мне нужно что-то предложить.
А теперь мне не хватает данных, что бы что-то предлагать. Даже не считаю что тезиса (1) достаточно для качественных предложений.
S>>Я пытаюсь выяснить, чем лучше архитектура, предложенная Мартином? Но конкретно, а не просто "удобнее". Удобнее чем что? Удобнее чем? Для какого типа приложений?
E>А зачем это выяснять? E>Ты все время пытаешься разговор куда-то в сторону увести.
— Она лучше
— Чем лучше?
— Ты все время пытаешься разговор увести
Ну ладно.
E>Ну какая разница какая архитектура лучше или хуже?
Если разницы нет, бери архитектуру God Project (по аналогии с God Object) и не парься над слоями.
E>Я уверен, что ты и сам понимаешь почему и зачем придуманы архитектуры.
Затем, что бы удовлетворять требованиям. Техническим, и не только. И мне представляется нелепым обсуждать то, чем такое расположение слоев лучше чем другое в контексте неопределенных требований. Собственно, я и пытаюсь склонить обсуждение к перечислению факторов, в рамках которых принято что одна архитектура лучше другой и слои должны взаимодействовать именно таким образом.
Если считаешь мои наводящие вопросы неконструктивными, то я найду куда пойти и чем заняться.
Здравствуйте, es3000, Вы писали:
S>>Я пример просто выдумал. Что бы ответить на эти вопросы, мне придется выдумать ответы. Но есть ли в этом какой-то смысл?
E>Я думаю, что смысл есть. E>А то странно получается: какие-то философские вопросы мы обсуждаем, а как только дело дошло до конкретного решения — "нет смысла"? E>Как будто ты избегаешь предложить конкретное решение.
Конкретное решение чего именно? Отправки сообщения?
S>>Принципиальна ли разница между сообщением и командой?
E>По моему мнению, с технической точки зрения — разницы нету. E>А вот с точки зрения назначения — есть.
E>А твое мнение? И как эта разница влияет на решение?
Не принципиальна, пока оба слоя разрабатываются и используются одной командой.
E>>>А что есть для "богатых"? S>>Теория категорий и монады
E>Когда-то пытался читать теорию категорий. Не понял ее практической применимости в программировании. E>Про монады не слышал, сейчас почитаю. E>Как теория категорий и монады могут помочь в озвученном вопросе?
Они позволяют представить источник событий монадой и связать их bind-ом с нужным кодом.
E>>>Если два слоя отправляют друг другу команды, тогда они оба связаны друг с другом. E>>>Они оба "равноправные", нету ни "вышестоящего" ни "нижележащего". S>>А если они отправляют команды не друг другу, а на деревню дедушке?
E>Опять одни вопросы. Ты кому вопросы задаешь? Тоже наверно на деревню дедушке? E>Что сказать то хочешь? Ты как будто стесняешься. E>Говори прямо — не стесняйся. E>Мне любое мнение интересно.
Хорошо, вот мой наводящий вопрос в форме утверждения:
Если слои отправляют команды не друг другу, а кому-то еще, то тогда они не будут связаны друг с другом.
E>>Я уверен, что ты и сам понимаешь почему и зачем придуманы архитектуры. S>Затем, что бы удовлетворять требованиям. Техническим, и не только. И мне представляется нелепым обсуждать то, чем такое расположение слоев лучше чем другое в контексте неопределенных требований. S>Собственно, я и пытаюсь склонить обсуждение к перечислению факторов, в рамках которых принято что одна архитектура лучше другой и слои должны взаимодействовать именно таким образом.
Ну так бы прямо и сказал: перечисли факторы такие-то и такие-то.
А то как-то не понятно что и к чему.
S>Если считаешь мои наводящие вопросы неконструктивными, то я найду куда пойти и чем заняться.
Я всегда "ЗА" общение, которое помогает решить проблему.
Только, пожалуйста, выражайся яснее.
S>До этого момента было обсуждение вопроса о том, "бывает ли такое". Никаких предложений не требовалось до сообщения, на которое я отвечаю. Я даже и подумать не мог, что мне нужно что-то предложить.
Ну как же...
Вот я прямо в первом сообщении написал (помимо "бывает ли такое"): "Если ... так делается, то как реализуется такое управление?
Как сделать внешний слой, о котором по сути Бизнес-логика ничего не знает, управляемым?"
S>А теперь мне не хватает данных, что бы что-то предлагать. Даже не считаю что тезиса (1) достаточно для качественных предложений.
Попробую объяснить подробнее.
Есть сложный бизнес-сценарий, который читает из БД данные, преобразует их, записывает в преобразованном виде во внешний файл, сохраняет в БД новые сформированные данные.
В этом сценарии много ответвлений, условий и "развилок", которые зависят от конкретного состояния данных, от результата выполнения действий с БД и файловой системой.
При возникновении этих развилок нужны дополнительные данные, которые надо запросить у пользователя.
И выполнение сценария продолжается в зависимости от ответа пользователя.
Каким образом запросить данные у пользователя так, чтобы не зависеть от слоя UI?
Ведь слой Бизнес-логики не должен зависеть от UI.
Очень упрощенный пример.
Мы в редакторе сохраняем файл, указываем имя.
Бизнес-логика при попытке сохранения файла обнаруживает, что такой файл уже существует.
Дальше она задает вопрос пользователю: "Что дальше делать?". Обычно предлагаются следующие варианты "Заменить, Сохранить под другим именем, Отменить".
Однако, таких вариантов может быть больше и они определяются возможностями бизнес-слоя.
Например, более "продвинутый" бизнес-слой мог бы предложить такие дополнительные варианты действий: "Дописать в существующий файл", "Сохранить под указанным именем переименовав существующий файл" и т. д.
S>>>Я пытаюсь выяснить, чем лучше архитектура, предложенная Мартином? Но конкретно, а не просто "удобнее". Удобнее чем что? Удобнее чем? Для какого типа приложений?
E>>Ну какая разница какая архитектура лучше или хуже? S>Если разницы нет, бери архитектуру God Project (по аналогии с God Object) и не парься над слоями.
Ты сам прекрасно понимаешь, почему так не следует делать.
Следуя твоему примеру, покажу как выглядит наш диалог с моей точки зрения:
— Я: "Как разделить слои"
— Ты: "Надо делить для конкретной цели"
— Я: "Цель такая-то. Как делить?"
— Ты: "Можешь не делить"
— Я: "Но лучше разделить. Как правильно разделить?"
— Ты: "А зачем делить?"
— Я: "За тем-то и затем-то"
— Ты: "Не обязательно делить"
S>Конкретное решение чего именно? Отправки сообщения?
Напоминаю: >> Вообще обычно бизнес-слой всем и управляет. Пример: пришла почта, нужно показать уведомление в UI. Кто инициатор? Логично что бизнес-слой.
Решение отображения уведомления в UI при поступлении почты.
Мне интересно как это правильно сделать по твоему мнению.
Какие действия при этом выполняются и какими объектами\слоями?
E>>Просто сообщение "пришла почта"? Или команду "покажи уведомление"? S>Принципиальна ли разница между сообщением и командой?
E>>По моему мнению, с технической точки зрения — разницы нету. E>>А вот с точки зрения назначения — есть.
E>>А твое мнение? И как эта разница влияет на решение?
S>Не принципиальна, пока оба слоя разрабатываются и используются одной командой.
И все-таки разница есть.
В случае сообщения, отправитель не ждет никакого ответа, его логика и дальнейшее поведение продолжается по прямолинейному алгоритму.
А в случае команды, важен результат ее обработки, поэтому логика отправителя зависит от ответа и далее разветвляется.
E>>Как теория категорий и монады могут помочь в озвученном вопросе? S>Они позволяют представить источник событий монадой и связать их bind-ом с нужным кодом.
S>Хорошо, вот мой наводящий вопрос в форме утверждения: S>Если слои отправляют команды не друг другу, а кому-то еще, то тогда они не будут связаны друг с другом.
Ты имеешь ввиду что-то типа шаблона "Медиатор"?
Про него выше говорили.
