Чтобы ответить на актуальный вопрос:
Прежде всего, это не всегда тот случай, когда ограничение базы данных соответствует ограничениям на стороне клиента. Поэтому было бы плохой идеей ограничивать себя проверкой только на основе ограничений базы данных.
Но опять же, вы хотите, чтобы ограничения базы данных были отражены в вашей модели данных. Таким образом, первое приближение, вероятно, было бы для определения некоторого небольшого набора perdicates, который сопоставим как с проверочными ограничениями, системным языком и javascript.
Либо так, либо вы просто позаботитесь о том, чтобы сохранить три представления в одном и том же месте, чтобы не забыть синхронизировать их при изменении чего-либо.
Но предположим, что вы хотите использовать другой набор ограничений, используемый в определенном контексте, где модель предметной области недостаточно ограничительна, или, возможно, это данные, которых вообще нет в модели. Вероятно, было бы неплохо, если бы вы могли использовать ту же конструкцию, которая использовалась для определения ограничения модели, для определения других видов ограничений.
Может быть, лучше всего определить небольшой управляемый DSL для perdicates, описывающих ограничение. Затем вы создаете «компиляторы», которые анализируют этот DSL и предоставляют необходимое представление.
«DSL» не обязательно должен быть такой простой, простой проверкой строк и проверкой int не является большой проблемой. Проверка RegEx может быть проблемой, если ваша база данных не поддерживает ее. Вероятно, вы можете спроектировать этот DSL как просто набор классов или то, что обеспечивает системный язык, который можно объединить в выражения с простой булевой алгеброй.