softwarer2. Я плохо отношусь к автогенеримому коду и полагаю, что единственный случай, когда он оправдан - убогие инструменты, не позволяющие решить задачу нормально. Но это отдельная тема, в которую вряд ли стоит особо углубляться.
Ладно не будем касаться данной темы, пока не возникнет очередной флейм, на тему "посмотрите я сделал универсальную систему по учету всего и вся". Хотя на мой взглад оправданность такого подхода определяется "количеством работников занимающихся разработкой", если их 3 на проекте то возможны все подходы, если больше десяти в одной конторе то стоит задуматься, а если десятки тысяч франчайзеров, локализаторов и пр. ничего иного я не вижу. Свой язык, свое ядро, свой инструмент разработки.

softwarer
Не совсем согласен, приведу другой пример. Хм. Если мы говорим об универсальной технологии, примеры, когда она работает хорошо никак не перекрывают примеров, когда она работает плохо. Она обязана либо [практически всегда] работать хорошо, либо же не будет универсальной.
Абсолютных решений не бывает, мы это уже обсуждали, полностью универсальное решение требует на порядок больше затрат чем прямое решение поставленной задачи. Универсальным я называю решение которое в 90 процентах случаев позволяет упростить и ускорить решение задач. И я не спорю что в 10 оставшихся процентах затраты на программирования могут быть искуственно завышены именно для того что-бы вписаться в рамки универсального решения.

softwarerИ? Не очень понял, что показывает этот пример. Да, так можно делать. При этом никто не мешает сделать проверку грамотно: еще в состоянии "редактируется", если заполнены обе даты и дата начала больше - ругаться. Потому как одно дело "еще не заполнено", другое - "уже заполнено криво".
Нет предела совершенству, но я исповедую подход минимально-необходимых проверок. На клиента такую проверку я бы все равно не вынес, в вот если бы пользователи часто ошибались именно в этом месте я бы действительно вставил проверку при сохранении документа.

softwarerКакая разница между этими вариантами.... мне вспоминаются старые компиляторы. Когда-то работа с диалоговыми комплексами шла примерно так: написал код, запускаешь компилятор, он показывает ошибку. Запускаешь редактор, исправляешь ее, выходишь из редактора, запускаешь компилятор, он показывает следующую ошибку. Было очень неудобно. Были хорошие компиляторы - которые показывали разом несколько ошибок, если могли продолжить компиляцию, пропустив ошибочный кусок. Это здорово ускоряло процесс. А сейчас компилятор показывает некоторые ошибки прямо в ходе набора текста - и оно еще удобнее.
К сожалению принципы общения с БД не располагают к "интерактивно-диалоговому" режиму. Это можно реализовать только "толстым" клиентом. Мне ближе по идеологии "тонкий" клиент.

А по поводу проверки всего и вся в БД, и у этого подхода есть свои подводные камни. Тут недавно всплывал пример того как человек стоял у кассы магазина и держал в руках товар, но не мог его купить, так как остаток товара в БД 0 и кассовый аппарат об этом недвухсмысленно сообщал. Жизнь к сожалению преподносит еще и не такие задачи, и списать со склада минус 3 килограмма гвоздей, это еще не самая сложная.