Comments 3
Я чето не понял как вы перешли от задачи семантической валидации JSON к сорс генераторам. Не притянуло ли за уши?
Дело в том, что 'семантическая валидация JSON' - это лишь часть задачи.
На деле могут происходить изменения, которые в моменте дёшево проверить не получится. Например, внешняя система добавила документ, а дальше по процессу выяснится, что документ уже недействительный и нужно выяснить, в какой момент и кто его добавил. Или был добавлен контакт, который почти полностью дублирует существующий. Если выяснится, что это действительно мусорный контакт-дубликат, а не полный тёзка с другой датой рождения, то нужно искать источник некорректных данных. Или внешняя система по ошибке удалила что то. Тут уж никак не проверишь.
В целом, кейсы могут быть очень разными, и, к тому же, сама структура периодически дополняется, и не все данные, присутствующие в JSON, мы используем у себя: часть мы просто пересылаем как есть и можем не знать про какую то логику, применимую к ним.
Немного не влип в суть происходящего..
Как что то может поменяться вообще? Я честно не очень себе представляю как вообще может измениться условно день рождения в рамках одной транзакции, если используется одна жирная БД на все сервисы, судя по моим наблюдениям. Это выглядит так, как будто это всё последствия ужасных архитектурщиков, которые плодят новые сервисы, забывая про экосистему, а потом такие "о, точно, мы сделали новый сервис который позволяет сделать встречи, но совсем забыли синхронизировать его со всей экосистемой" и это выливается в заклеивании трещин скотчем на скотч или может быть я чего не то не понял.
А в целом, сорс гены могут быть полезны, но я не очень их люблю. Самый яркий и запоминающийся мне случай их использования, это генерация кучи энтити содержащих физические переменные с жирными, но одинаковыми get;set;, маской вычисления и их порядком. Такое конечно не объединить в интерфейс или абстракный класс, логика одна, но работает это всё по маске и порядку, а в зависимости от маски и порядка, всё разное, и, в этом случае, это можно сказать единственный, облегчающий работу и расширяемость, самый яркий кейс, куда я за почти 3 года мог применить сорс ген. Но как верно подмечено, импакт будет лишь тогда, когда генератор можно написать в/на порядок меньшее количество строчек и времени с учётом будущего, чем это потребовалось бы без него, например всякие INotifyPropertyChanged, которые экономят 9 строчек, исключения ~17, мапперы, когда на проект нельзя подключить нугет пакет и т.д. А то выйдет так, что на написание уйдёт 10 часов для генерации всего лишь трёх классов, а ручками за это время можно будет их сделать более сотни, прощай эффективность и тайм-менеджмент, да здравствует магия и автоген.
К слову, про перевернуть мышление, верно сказано) Осознать, что больше не требуется тратить кучу времени и писать кучу повторяющегося кода, например, для исключений и привязок, а лишь объявить их в одну строчку и использовать весь функционал - это действительно круто, до тех пор, пока твои коллеги не спросят тебя, как этим пользоваться, потому что они не понимают, что происходит или не убьют весь твой феншуй, для которого ты старался и писал сорсген, обычными полноценными классами, а не сокращением в одну строчку :(
Пишем код, когда пишем код: сорс-генераторы