Comments 25
Мнения как минимум не однородные. Видимо есть разные задачи. Прошу поделится своими примерами задач, и пояснить почему вы исходите из бизнес-логики или из чего-то другого.
важные вещи, сразу по изменению состояния. те, которые меняются часто и не так важны, по таймеру.
бизнес-логика — массивное, абстрактное понятие, описывающее общие принципы порядка взаимодействия узлов и компонентов приложения и пользователя.
Выбор места хранения данных определяется следующими критериями:
1. Доступность. Определяет быстродействие, порядок доступа (RW|R|W) и пр.
2. Целостность. Определяет критичность данных и восстанавливаемость при сбое.
К примеру: запись данных в мемкэш или тиблицы типа MEMORY определяются критериями высокой скорости доступности и не критичностью к сбою (при очистке таблиц при отключении или перезапуске) приложение сохраняет работоспособность.
ИЛИ
Запись данных в INNODB где получаем высокую надежность и целостность данных, но жертвует скоростью.
может быть сумбурно описал и сильно грубые примеры, но в действительности как-то так.
Выбор места хранения данных определяется следующими критериями:
1. Доступность. Определяет быстродействие, порядок доступа (RW|R|W) и пр.
2. Целостность. Определяет критичность данных и восстанавливаемость при сбое.
К примеру: запись данных в мемкэш или тиблицы типа MEMORY определяются критериями высокой скорости доступности и не критичностью к сбою (при очистке таблиц при отключении или перезапуске) приложение сохраняет работоспособность.
ИЛИ
Запись данных в INNODB где получаем высокую надежность и целостность данных, но жертвует скоростью.
может быть сумбурно описал и сильно грубые примеры, но в действительности как-то так.
Бизнес-логика — это «когда пользователь в настройках отметил такие-то галочки и произошло событие такое-то, должно произойти следующее». БД, объекты и время их сохранения — это детали реализации. Если заказчик говорит вам, как писать код, а не что он хочет получить, значит что-то не так.
А если заказчик четко знает как это писать, но ему самому не хватает человеческих ресурсов для написания? Тогда он будет говорить вам как писать код.
Человек, исполняющий роль заказчика, по определению не знает деталей реализации и тем более не учит программистов, как им работать. Если только какой-нибудь тимлид или программист-одиночка одновременно не является заказчиком.
По хорошему тогда надо разобраться в этих заказчиках. Потому как вы правильно отметили как минимум два типа уже — тимлид или программист-одиночка. А еще есть довольно крупные организации, которые готовят четкое ТЗ от и до (то есть как писать), а кто-то на аутсорсе его реализует.
А вот к группа заказчиков, которая «по определению не знает деталей реализации» у меня вызывает скорее удивление.
Или под ролью заказчика не может быть группа / организация в вашем понимании?
А вот к группа заказчиков, которая «по определению не знает деталей реализации» у меня вызывает скорее удивление.
Или под ролью заказчика не может быть группа / организация в вашем понимании?
Извините, но кажется вы вместе с вашими заказчиками курите.
Да, а как же выглядит это все с вашими заказчиками? Кстати, я как раз скорее заказчик, который по определению знаю детали того, что заказываю. А ранее был исполнителем и работал с заказчиками, которые по определению знали. Где вы других берете? Мне правда интересно.
Обычно это выглядит так. Заказчик объясняет, что хочет получить, а программист или программисты ему это пишут. Иногда заказчик сам точно не знает, чего хочет, потому приходится задавать уточняющие вопросы или показывать пару прототипов, но суть та же. Часто заказчику попросту не хватает технической грамотности, чтобы понять детали реализации. Тем же, которым хватает, обычно не интересно в это лезть. Где беру? Повсеместно, мне другие и не попадались.
почему вы исходите из бизнес-логики или из чего-то другого
Из бизнес-логики. Потому что именно бизнес-логика определяет схемы работы, в том числе и БД.
Если пользователь нажал кнопку «Сохранить», то сохранение данных произойдет из-за того, что в бизнес-логике описана последовательность действий, включающих в себя сохранение, и выполняемых по клику на кнопку «Сохранить».
*в том числе и с БД
Я вот тоже разделяю подобное мнение, но меня тут пытались убедить, что это не так. Видима проблема не такая простая как на первый взгляд, и сильно зависит от личности программиста :)
Для подобных вопросов есть твитор или классный руководитель в школе.
У нас тут спор завязался, вот решил выяснить просто статистически см. Отделение логики базы данных. Оказывается не все так линейно, но во всяком случае я рад, что мое мнение соответствует 2/3 мнений людей.
Простите, не понимаю смысла вопроса. Исходя из бизнес-логики чаще всего состояния сохраняются в гуевых дестопных приложениях. С другой стороны, вполне нормален вариант сериализации объекта в файл, скажем, между двумя запусками какой-нибудь консольной утилиты/демона, и это, скорее всего, не обусловлено бизнес-логикой. Таким образом, ответ на ваш вопрос в немалой степени будет зависеть от типа приложений, которые пишет программист.
Но я же выше и прошу уточнить — для каких задача так, а для каких иначе — если вы не готовы выбрать один из ответов.
Я понял, да. Сам проголосовал за вариант с бизнес-логикой (в моей практике такого гораздо больше), а потом подумал и решил, что результаты опроса будут бесполезны без контекста. Ну быть может, косвенно определят соотношение системщиков и прикладников :)
Я бы сказал так — я бы отделял состояние объекта от него самого. Бизнес-объекты сохранял бы исходя из бизнес-логики.
А в принципе писать можно, когда надо. Например, полузаполненная форма может бизнес-объектом не являться, но не вижу ничего, чтобы мешало ее сохранить.
А в принципе писать можно, когда надо. Например, полузаполненная форма может бизнес-объектом не являться, но не вижу ничего, чтобы мешало ее сохранить.
UFO just landed and posted this here
В идеале система должна поддерживать прозначную персистентность, то есть сохранение данных в базу должно быть независимо от бизнес-логики. На уровне бизнес-логики мы только определяем когда изменять состояние объекта. А база-данных — это тень объекта, которая постоянна должна его отражать.
Правильный пункт — 2 хоть он и выделен как «другое» а не основной.
Правильный пункт — 2 хоть он и выделен как «другое» а не основной.
Sign up to leave a comment.
Мы решаем когда сохранять состояние объекта (в базу данных, любое другое хранилище) исходя: