2009-09-10 4 views
4

Я играл с валидатором nhibernate и получил почти идеальное решение.как проверить пользовательские свойства?

Я могу определить свойство, подлежащее проверке, и это делается при предварительном сохранении. Но у меня есть случаи, когда он не работает.

Предположим, у меня есть объект, называемый человеком, и через nhibernate я сопоставил адрес (также объект) как свойство человека (фактически это список адресов).

Когда я сохраняю человека, мой адрес не подтвержден.

Форма для ввода информации состоит из частных форм. Было бы неплохо, если бы проверка адреса могла быть добавлена ​​в список проверки личности, но это не требуется.

Мне нужно общее решение, я не могу подтвердить его «рукой», например. если человек затем подтверждает адрес ... Как-то валидатор должен видеть, что есть объект за свойством, который я также должен проверить.

Обновление: то, что я ищу, является способом проверки отображаемых объектов (hasmany).

+0

Можете ли вы опубликовать часть своего исходного кода, в частности, как валидатор прикреплен к интересующему столбцу/коллекции? –

+0

В классе, где у меня есть свойства NHibernate валидатор позволяет мне определить что-то вроде : публичная виртуальная строка foofield {получить, установить;} Скажем, у меня есть [NotNullNotEmpty (Message = «Foofield Пожалуйста, заполните в чем-то.»)] человек класса и есть адрес класса. Поэтому я отображаю в классе человека hasmany

, при сохранении человека адреса не проверяются. Если я вызываю save на каждом из них, они проверяются ... Но это определенно не решение;) – griti

ответ

1

После перехода на новейшую версию валидатора nhibernate проверка выполняется для подклассов и сопоставленных классов. Вместе с xVal 1.0 это очень удовлетворительное решение.

Теперь я могу определить для каждого свойства то, что он должен быть проверен (например, для регулярного выражения, длины и т. Д.), И я получаю сообщение на стороне клиента через xVal на стороне сервера через nHibernate Validator. Фактически они используют шаблон проверки и сообщения об ошибках.

Я бы рекомендовал это для любого проекта nHibernate, где требуется простое определение для проверки и обмена сообщениями.

1

Если вы пытаетесь выполнить проверку ввода в этих классах, что я думаю, что вы пытаетесь сделать, я бы посоветовал это сделать, поскольку это бизнес-логика. Все, что вы найдете в Hibernate, которое делает это, делает это только для обеспечения ограничений в базе данных (т. Е. Столбца, отличного от нуля).

Что я хотел бы рекомендовать, так это то, что вы создаете класс или метод утилиты для проверки ввода. Если вам нужно добавить ограничения базы данных к свойствам сущности, обязательно сделайте это, но я бы не стал полагаться на них для проверки ввода.

+1

Мне нужны и валидация, и подтверждение валидации на стороне бизнес-логики/сервера. С xVal и nHibernate я получаю оба без усилий. См. Мой ответ, мы писали примерно в то же время :) +1 для того, чтобы пообщаться с моей проблемой;) Вообще я согласен с вашими предложениями, я искал готовое решение, написав это сам, на этот раз было бы много накладных расходов , – griti

Смежные вопросы