B
Size: a a a
2019 June 15
OG
Все стремятся показаться культурными )
2019 June 16
SZ
Вызывает интерес
ваш технический прогресс.
Как у вас там в базы залють, с мидлваров* али без? * мидлвары - (req, res, next) или (ctx, next)
ваш технический прогресс.
Как у вас там в базы залють, с мидлваров* али без? * мидлвары - (req, res, next) или (ctx, next)
Анонимный опрос
0%
Запросы к БД прямо из мидлваров и бизнес-логика там же
0%
Запросы в бизнес-логике, но абстрагированы от HTTP
0%
Запросы в слое доступа к БД, а бизнес-логика в мидлварах
0%
Три слоя: доступ к БД, бизнес-логика, сетевые обработчики
Пишу для себя небольшую заметку по архитектуре. Вот абзац из нее. Как вам такие мысли ?
Controller >> Service layer >> Business layer >> Data layer
Controller(роутинг) >> Action(логика) >> Data Layer(биндинги к БД)
Несколько слов про разделение приложения на слои:
Часто в интрнетах встречается подобная архитектура. Или еще чего более мнегослойное.
Controller >> Service layer >> Business layer >> Data layer
В средних и более крупных проектах для организации логики приложения используют два таких слоя как `Business layer` и `Service layer`. В двух словах: `Business layer` полностью изолирует бизнес процессы, а `Service layer` валидирует и подготавливает данные для бизнес логики и вызывает ее для дальнейшей отправки полученного результа в контроллер. Или иначе ? Как вы считаете ? Каждый программист делает как считает нужно. Давайте будем откровенны. Приводило ли подобная архитектура к тому ради чего задумывалась(к порядку и разделению логики) ? Зачастую все эти попытки сводятся к `big ball of mud`. Дабы так не происходило было принято решение сделать единый слой для всей логики касаемой конкетного `use case`. Назовем этот слой `Action layer`. Да это логически мешает несколько слоев в один. Но в итоге с таким подходом мы имеем больше порядка в коде чем было описано выше. Да такой подход скорее всего будет работать для небольших и средних проектов. Энтерпраз всегда жил и будет жить своим аутентичным миром. Что в итоге нам нравится разрабатывать ? Код который просто читается и который мы понимаем или спорить(ломать голову) в каком слое должен находится какой кусок кода ?
В своих проектах я придерживаюсь трех трехслойного подхода.
Controller(роутинг) >> Action(логика) >> Data Layer(биндинги к БД)
OG
имхо тут очень много мыслей свалено в одну кучу.
как минимум идея слоев взята из концепции многослойной архитектуры, в которой контроллер -- это шаблон, применяемый в концепции сервисного слоя.
здесь же, насколько я могу понять, контроллер представлен как сущность из MVC (или ее производных) архитектуры и используется в другом значении.
сама по себе идея не плодить ненужные сущности правильна и давно известна. но говорить о том, как делать лучше, нельзя без конкретного примера. что если у нас есть небольшое по размеру приложение с очень сложной логикой? или наоборот, очень большое, но бизнес-логика в нем сводится к "провалидируй и положи в бд"?
и да, обороты типа: "или наче?" лично у меня вызывают неприязнь. ничего личного
как минимум идея слоев взята из концепции многослойной архитектуры, в которой контроллер -- это шаблон, применяемый в концепции сервисного слоя.
здесь же, насколько я могу понять, контроллер представлен как сущность из MVC (или ее производных) архитектуры и используется в другом значении.
сама по себе идея не плодить ненужные сущности правильна и давно известна. но говорить о том, как делать лучше, нельзя без конкретного примера. что если у нас есть небольшое по размеру приложение с очень сложной логикой? или наоборот, очень большое, но бизнес-логика в нем сводится к "провалидируй и положи в бд"?
и да, обороты типа: "или наче?" лично у меня вызывают неприязнь. ничего личного
TS
Пишу для себя небольшую заметку по архитектуре. Вот абзац из нее. Как вам такие мысли ?
Controller >> Service layer >> Business layer >> Data layer
Controller(роутинг) >> Action(логика) >> Data Layer(биндинги к БД)
Несколько слов про разделение приложения на слои:
Часто в интрнетах встречается подобная архитектура. Или еще чего более мнегослойное.
Controller >> Service layer >> Business layer >> Data layer
В средних и более крупных проектах для организации логики приложения используют два таких слоя как `Business layer` и `Service layer`. В двух словах: `Business layer` полностью изолирует бизнес процессы, а `Service layer` валидирует и подготавливает данные для бизнес логики и вызывает ее для дальнейшей отправки полученного результа в контроллер. Или иначе ? Как вы считаете ? Каждый программист делает как считает нужно. Давайте будем откровенны. Приводило ли подобная архитектура к тому ради чего задумывалась(к порядку и разделению логики) ? Зачастую все эти попытки сводятся к `big ball of mud`. Дабы так не происходило было принято решение сделать единый слой для всей логики касаемой конкетного `use case`. Назовем этот слой `Action layer`. Да это логически мешает несколько слоев в один. Но в итоге с таким подходом мы имеем больше порядка в коде чем было описано выше. Да такой подход скорее всего будет работать для небольших и средних проектов. Энтерпраз всегда жил и будет жить своим аутентичным миром. Что в итоге нам нравится разрабатывать ? Код который просто читается и который мы понимаем или спорить(ломать голову) в каком слое должен находится какой кусок кода ?
В своих проектах я придерживаюсь трех трехслойного подхода.
Controller(роутинг) >> Action(логика) >> Data Layer(биндинги к БД)
Мысли правильные, а подача путаная. Для любого сервера, который имеет доступ к БД и бизнес-логику и API для доступа к этой логике нужно минимум три слоя: слой доступа к данным, который содержит пул соединений с БД и строит запросы, слой бизнес логики, в который не должны попадать ни конекшены к бд, ни сокеты или сетевые контексты (req, res, client, ctx, socket...) и слой сетевой, который принимает запросы, парсит пакеты, маршрутизирует запросы в модули и функции, формирует пакеты ответов. Лучше всего на этих трех слоях и остановиться, но не всегда это возможно. Например, бывает нужно вставлять слои и прослойки: проксирование или софтварная балансировка с перенаправлением запросов в другие процессы или другие сервера, кеширование, аутентификация по внешней системе, запуск кода в изолированных контекстах, использование ORM с адскими преобразованиями данных пустого в порожнее, спаси нас Аллах от этого.
OG
вообще я перечитал и понял, что, пожалуй, концепция как раз полностью вкладывается в Service(Application) Layer (представлена одним контроллером-роутером) » Business Layer, который автор назвал Action Layer » Data Layer.
TS
вообще я перечитал и понял, что, пожалуй, концепция как раз полностью вкладывается в Service(Application) Layer (представлена одним контроллером-роутером) » Business Layer, который автор назвал Action Layer » Data Layer.
👍 классика, просто слова controller, action, service - вызывают ложные ассоциации и я их не рекомендую использовать, если только вы не говорите с человеком, который уже и так вас хорошо понимает, находится в том же контексти или вообще, в том же проекте
OG
к сожалению да, вопрос терминологии стоит очень остро. и часто нужно время на то, чтобы просто понять друг друга
TS
Пишу для себя небольшую заметку по архитектуре. Вот абзац из нее. Как вам такие мысли ?
Controller >> Service layer >> Business layer >> Data layer
Controller(роутинг) >> Action(логика) >> Data Layer(биндинги к БД)
Несколько слов про разделение приложения на слои:
Часто в интрнетах встречается подобная архитектура. Или еще чего более мнегослойное.
Controller >> Service layer >> Business layer >> Data layer
В средних и более крупных проектах для организации логики приложения используют два таких слоя как `Business layer` и `Service layer`. В двух словах: `Business layer` полностью изолирует бизнес процессы, а `Service layer` валидирует и подготавливает данные для бизнес логики и вызывает ее для дальнейшей отправки полученного результа в контроллер. Или иначе ? Как вы считаете ? Каждый программист делает как считает нужно. Давайте будем откровенны. Приводило ли подобная архитектура к тому ради чего задумывалась(к порядку и разделению логики) ? Зачастую все эти попытки сводятся к `big ball of mud`. Дабы так не происходило было принято решение сделать единый слой для всей логики касаемой конкетного `use case`. Назовем этот слой `Action layer`. Да это логически мешает несколько слоев в один. Но в итоге с таким подходом мы имеем больше порядка в коде чем было описано выше. Да такой подход скорее всего будет работать для небольших и средних проектов. Энтерпраз всегда жил и будет жить своим аутентичным миром. Что в итоге нам нравится разрабатывать ? Код который просто читается и который мы понимаем или спорить(ломать голову) в каком слое должен находится какой кусок кода ?
В своих проектах я придерживаюсь трех трехслойного подхода.
Controller(роутинг) >> Action(логика) >> Data Layer(биндинги к БД)
Тут есть несколько лекций по этим вопросам:
https://youtu.be/d_vyO2CkiOc
https://youtu.be/CRcSWtWVvrA
https://youtu.be/-az912XBCu8
https://youtu.be/2tDvHQCBt3w
https://youtu.be/d_vyO2CkiOc
https://youtu.be/CRcSWtWVvrA
https://youtu.be/-az912XBCu8
https://youtu.be/2tDvHQCBt3w
TS
к сожалению да, вопрос терминологии стоит очень остро. и часто нужно время на то, чтобы просто понять друг друга
Программистам нужно обязательно давать почитать Витгенштейна
OG
надо и мне почитать )
SZ
вообще я перечитал и понял, что, пожалуй, концепция как раз полностью вкладывается в Service(Application) Layer (представлена одним контроллером-роутером) » Business Layer, который автор назвал Action Layer » Data Layer.
Все так) Единственное я в БЛ делаю валидацию входящих данных. То есть знаю про запрос. Что не очень хорошо. Но делаю осознанно. По причинописанной выше
SZ
Если интересно вот пример Action
https://github.com/zmts/supra-api-nodejs/blob/master/actions/users/CreateAction.js
https://github.com/zmts/supra-api-nodejs/blob/master/actions/users/CreateAction.js
OG
не факт. можно передавать данные не передавая запрос.
если посмотреть, в коде есть обращение только к req.body. соответственно можно передать body не передавая req
если посмотреть, в коде есть обращение только к req.body. соответственно можно передать body не передавая req
OG
и валидация не пострадает и лишнего Action знать не будет
SZ
OG
тогда в чем вопрос? что валидация данных происходит в слое бизнес логики? чем это так критично плохо?
SZ
Собственно да. Действительно настолько ли критично заниматься валидацией в БЛ ?
OG
Я бы сказал что в этом случае нет. Валидация вызывается из контроллера. Если возникнет сильное желание написать отдельный валидатор в сервисном слое, рефакторинг займет очень мало времени.
К тому же сам по себе вопрос очень и очень зависит от условий.
У нас есть клерк, задача которого принимать бланки. Он отдает бланки операционисту. Кто должен проверять, правильно ли клиент заполнил бланк? Зависит от того как организована работа, от загрузки этих людей, еще от кучи факторов. А директора в общем случае заботит лишь то чтобы проверка хоть где-то но выполнялась.
К тому же сам по себе вопрос очень и очень зависит от условий.
У нас есть клерк, задача которого принимать бланки. Он отдает бланки операционисту. Кто должен проверять, правильно ли клиент заполнил бланк? Зависит от того как организована работа, от загрузки этих людей, еще от кучи факторов. А директора в общем случае заботит лишь то чтобы проверка хоть где-то но выполнялась.
