И когда это будет возможно, я не знаю. Когда-то я обращался в администрацию Губернатора МО с вопросом о том, не планируется ли создание единого кабинета, в котором можно было бы оплачивать все коммунальные счета. Ну, то есть, по задумке, ГИС ЖКХ и должен быть таким кабинетом. Но пока, видимо, не всё ещё работает, как положено. А когда заработает – неизвестно.
Вообще, в нашей местности коммунальные платежи – это притча во языцех. Когда ещё не было возможности оплачивать счета через интернет, квитанция менялась каждые полгода, и разобраться в этом не было никакой возможности.
Дело в том, что я не могу передавать показания через ГИС ЖКХ. Там есть только счётчики воды, электросчётчика нет. Если я пытаюсь передать показания счётчиков, я получаю сообщение
Внимание! Передача показаний по следующим приборам учета невозможна, т.к. по договору, на основании которого заведен лицевой счет, указанный в приборе учета, услуга по подаче коммунального ресурса не предоставляется.
Прибор учета № 204933, Горячая вода обратитесь в организацию "ООО "ЮГО-ЗАПАДНОЕ"";
…
А что касается тепла, в нашем городе эти услуги предоставляет организация Глобус, и платить можно либо в личном кабинете, либо по квитанции или перечислением на счёт.
Ну что вы, какой API! Спасибо ещё, что кабинеты разработали. Что касается кабинета Глобуса, делали его, скорее всего, силами студентов. А так да, API был бы очень полезен…
Спасибо за ссылку. Мысль использовать видеокамеру для снятия показаний приходит в голову многим. Впечатляет, что здесь обработка изображения и прогон через нейросеть осуществляется in-place.
С другой стороны, сейчас уже идут в основном импульсные счётчики воды, так что автоматическая передача значений уже не проблема.
Согласен. Во многих новомодных технологиях производства часто больше идеологической мишуры, чем дела. А примеры самоорганизующихся команд-артелей можно найти и в глубокой древности.
Эмм… Так я же так и делаю! Вьюшка или глобальный фильтр мне не подошли.
Но насчёт детского сада вы, может быть, и правы.
Разумеется, ничего принципиально нового в этой статье нет. Просто я считаю, что моя цель достигнута, если хотя бы паре человек это пригодится.
Главная идея здесь — интерпретация метода DELETE как перемещения ресурса в архив. В начале работы это было совсем неочевидно.
И кстати: речь шла о переводе всего объекта в новое состояние, так что метод PUT вполне мог рассматриваться в качестве альтернативы DELETE.
Хотя, стандарт определяет, что сохранять надо именно под URL запроса:
The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server.
Да, вы правы.
Правда, в контексте статьи неважно о каком методе шла речь.
На всякий случай, переправил PUT на PATCH, чтобы это не вызывало у людей недоумения.
Дельное замечание. Но вот какая штука: я специально расставил трассировки и убедился в том, что в случае Task.Run создаётся один поток до первого await и другой после.
Вопрос в том, стоит ли плодить лишние потоки?
Мысль интересная, буду держать её в голове.
Тем более, что сейчас алгоритм обновления выглядит следующим образом:
Обновляем компанию пользователя
Получаем компанию из БД
Если такой компании нет, добавляем новую компанию в БД
Если компания изменилась, обновляем компанию в БД
То же самое для пользователя
Пока пользователей у нас немного, поэтому проблем с загрузкой СУБД нет. Если появятся – подумаем над вашим предложением.
Но должен отметить, что если используется вышеописанный алгоритм, загрузка СУБД будет одинаковой вне зависимости от того, выполняется обновление в фоне или в самом запросе.
Вот тут-то и возникает тот конфликт интересов, о котором я писал.
Готов понять обоснованность такого решения, но когда вижу, что проект разрублен топором по живому, для меня это что нож в сердце. Да, в организационном плане, возможно, выиграли, но гармония уже нарушена.
А потом вдруг организационная структура изменится, так что, опять кромсачить будем?
Я исхожу из предположения, что контроллеры у нас тоже асинхронные. В этом случае синхронные версии методов не нужны.
а оттуда выбрасывал бы что-то более значимое для доменной области. Например, DuplicatedUserException.
Это исключение не нужно, оно не имеет смысла. Если произошло primary key violation, значит, в данный момент другой поток выполняет работу по обновлению базы. Он её и закончит.
Постарался объяснить это более подробно в статье, спасибо за комментарий.
Это точка зрения бизнеса. Конечная цель – максимум прибыли. И это правильно. Мне, как разработчику, эта цель тоже близка, потому что я тоже заинтересован в успехе продукта.
Но у меня есть и другая цель. Мне важно, чтобы мой проект был гармоничным, я хочу стремиться к совершенству. Я хочу, чтобы я мог гордиться тем, что сделал, чтобы люди могли сказать: «О, смотрите, этот парень сделал крутую вещь! ».
И тут порой бывает так, что мои интересы противоречат интересам бизнеса. Бизнесу может быть нужно сделать что-то вот прямо сейчас. Бизнес не интересуют мои амбиции. Бизнес может не волновать внутреннее качество продукта, если в данный момент удовлетворение клиента важнее возможных противоречий и несогласованностей в системе.
Про этот конфликт интересов я и хотел сказать. Судя по всему, мне это не очень удалось. Если подскажете, как можно переработать статью и стоит ли вообще это делать – буду признателен.
Я, собственно, не про технологии писал. Я хотел сказать, что в отличие от бизнеса, для разработчика самым важным критерием является качество. Это то, чем человек может гордиться в будущем. Когда вам приходится скрепя сердце выполнять решение, калечащее ваш проект, вам ведь нелегко, правда? Поэтому разработчик должен по возможности противиться непродуманным решениям.
Вы всё правильно говорите. Только я ведь не про Аджайл писал, в общем-то. Неважно, какая технология разработки используется, главное – чтобы решения принимались продуманно и ответственно.
Изменил подход и переработал статью в соответствии с вашими замечаниями. Основная идея в том, что сервис должен уметь отвечать на запрос OPTIONS как для авторизованного, так и для неавторизованного пользователя. Этот подход успешно работает в реальном приложении.
Если бы мне задавали подобные вопросы на собеседовании, я был бы очень рад. Прекрасно, когда вместо экзамена собеседование превращается в общение будущих потенциальных коллег к обоюдному удовольствию!
Вопросы, в целом, хороши, поскольку они предполагают рассуждения, а не заученные ответы.
Увы, не получается, см. выше.
И когда это будет возможно, я не знаю. Когда-то я обращался в администрацию Губернатора МО с вопросом о том, не планируется ли создание единого кабинета, в котором можно было бы оплачивать все коммунальные счета. Ну, то есть, по задумке, ГИС ЖКХ и должен быть таким кабинетом. Но пока, видимо, не всё ещё работает, как положено. А когда заработает – неизвестно.
Вообще, в нашей местности коммунальные платежи – это притча во языцех. Когда ещё не было возможности оплачивать счета через интернет, квитанция менялась каждые полгода, и разобраться в этом не было никакой возможности.
Дело в том, что я не могу передавать показания через ГИС ЖКХ. Там есть только счётчики воды, электросчётчика нет. Если я пытаюсь передать показания счётчиков, я получаю сообщение
А что касается тепла, в нашем городе эти услуги предоставляет организация Глобус, и платить можно либо в личном кабинете, либо по квитанции или перечислением на счёт.
Ну что вы, какой API! Спасибо ещё, что кабинеты разработали. Что касается кабинета Глобуса, делали его, скорее всего, силами студентов. А так да, API был бы очень полезен…
Спасибо за ссылку. Мысль использовать видеокамеру для снятия показаний приходит в голову многим. Впечатляет, что здесь обработка изображения и прогон через нейросеть осуществляется in-place.
С другой стороны, сейчас уже идут в основном импульсные счётчики воды, так что автоматическая передача значений уже не проблема.
Эмм… Так я же так и делаю! Вьюшка или глобальный фильтр мне не подошли.
Но насчёт детского сада вы, может быть, и правы.
Разумеется, ничего принципиально нового в этой статье нет. Просто я считаю, что моя цель достигнута, если хотя бы паре человек это пригодится.
Главная идея здесь — интерпретация метода DELETE как перемещения ресурса в архив. В начале работы это было совсем неочевидно.
Хотя, стандарт определяет, что сохранять надо именно под URL запроса:
Так что ещё раз: вы правы.
Правда, в контексте статьи неважно о каком методе шла речь.
На всякий случай, переправил PUT на PATCH, чтобы это не вызывало у людей недоумения.
Вопрос в том, стоит ли плодить лишние потоки?
На всякий случай, я пробовал такой код:
Но если СУБД перегружена, стоит, видимо, задуматься о системном решении этой проблемы в первую очередь?
Тем более, что сейчас алгоритм обновления выглядит следующим образом:
Пока пользователей у нас немного, поэтому проблем с загрузкой СУБД нет. Если появятся – подумаем над вашим предложением.
Но должен отметить, что если используется вышеописанный алгоритм, загрузка СУБД будет одинаковой вне зависимости от того, выполняется обновление в фоне или в самом запросе.
Готов понять обоснованность такого решения, но когда вижу, что проект разрублен топором по живому, для меня это что нож в сердце. Да, в организационном плане, возможно, выиграли, но гармония уже нарушена.
А потом вдруг организационная структура изменится, так что, опять кромсачить будем?
В том то и дело, что «вынуждена». Но вот правильно ли это — большой вопрос…
Почему?
Не совсем понял, что вы имели в виду.
Это исключение не нужно, оно не имеет смысла. Если произошло primary key violation, значит, в данный момент другой поток выполняет работу по обновлению базы. Он её и закончит.
Постарался объяснить это более подробно в статье, спасибо за комментарий.
Это точка зрения бизнеса. Конечная цель – максимум прибыли. И это правильно. Мне, как разработчику, эта цель тоже близка, потому что я тоже заинтересован в успехе продукта.
Но у меня есть и другая цель. Мне важно, чтобы мой проект был гармоничным, я хочу стремиться к совершенству. Я хочу, чтобы я мог гордиться тем, что сделал, чтобы люди могли сказать: «О, смотрите, этот парень сделал крутую вещь! ».
И тут порой бывает так, что мои интересы противоречат интересам бизнеса. Бизнесу может быть нужно сделать что-то вот прямо сейчас. Бизнес не интересуют мои амбиции. Бизнес может не волновать внутреннее качество продукта, если в данный момент удовлетворение клиента важнее возможных противоречий и несогласованностей в системе.
Про этот конфликт интересов я и хотел сказать. Судя по всему, мне это не очень удалось. Если подскажете, как можно переработать статью и стоит ли вообще это делать – буду признателен.
Я, собственно, не про технологии писал. Я хотел сказать, что в отличие от бизнеса, для разработчика самым важным критерием является качество. Это то, чем человек может гордиться в будущем. Когда вам приходится скрепя сердце выполнять решение, калечащее ваш проект, вам ведь нелегко, правда? Поэтому разработчик должен по возможности противиться непродуманным решениям.
Вопросы, в целом, хороши, поскольку они предполагают рассуждения, а не заученные ответы.