Какие классы следует сопоставлять с NHibernate?

Question

В настоящее время мы используем NHibernate для сопоставления бизнес-объектов с таблицами базы данных. Указанные бизнес-объекты обеспечивают соблюдение бизнес-правил: аксессоры набора будут выставлять исключение на месте, если контракт на это имущество нарушен. Кроме того, свойства обеспечивают связь с другими объектами (иногда двунаправленными!). Ну, всякий раз, когда NHibernate загружает объект из базы данных (например, когда вызывается ISession.Get (id)), набор аксессуаров сопоставленных свойств используется для помещения данных в объект.

Хорошо, что средний уровень приложения обеспечивает бизнес-логику. Плохо то, что в базе данных нет. Иногда дерьмо находит свой путь в базе данных. Если в приложение загружается дерьмо, он освобождает (генерирует исключение). Иногда это явно должно залогодержаться, потому что он ничего не может сделать, но что, если он может продолжать работать? Например, средство администрирования, которое собирает отчеты в режиме реального времени, имеет высокий риск неудачи без необходимости, а не позволяет администратору даже исправить (потенциальную) проблему.

У меня нет примера на мне прямо сейчас, но в некоторых случаях, позволяя NHibernate использовать свойства «входной двери», которые также обеспечивают соблюдение отношений (особенно bidi), приводит к ошибкам.

Каковы наилучшие решения?

В настоящее время я, на основе каждой собственности, создать «заднюю дверь» только для NHibernate:

public virtual int Blah {get {return _Blah;} set {/*enforces BR's*/}} 
protected virtual int _Blah {get {return blah;} set {blah = value;}} 
private int blah; 

я показал выше, в C# 2 (свойств не по умолчанию), чтобы продемонстрировать, как это становится нас в основном 3 слоя, или взглядов, к бла-бла !!! Хотя это, безусловно, работает, оно не кажется идеальным, так как BL требует предоставить один (общедоступный) интерфейс для приложения в целом и другой (защищенный) интерфейс для уровня доступа к данным.

Существует дополнительная проблема: Насколько я знаю, NHibernate не дает вам возможности различать имя свойства в BL и имя свойства в модели сущности (то есть имя, которое вы используете, когда вы запрос, например, через HQL - всякий раз, когда вы даете NHibernate имя (строка) свойства). Это становится проблемой, когда сначала BR для некоторого свойства Blah не проблема, поэтому вы ссылаетесь на него в своем сопоставлении O/R ... но потом вам нужно добавить некоторые BR, которые действительно становятся проблемой, поэтому то вам нужно изменить свое сопоставление O/R, чтобы использовать новое свойство _Blah, которое разбивает все существующие запросы с помощью «Бла» (общая проблема с программированием против строк).

Кто-нибудь решил эти проблемы ?!

Answer 1

В то время как я нашел большую часть вашей архитектуры проблемой, обычный способ справиться с этим материалом - использовать NHibernate для поля поддержки вместо setter.

В приведенном выше примере вам не нужно определять дополнительное защищенное свойство. Просто используйте это в отображении:

<property name="Blah" access="nosetter.lowercase"/> 

Это описано в документации, http://nhibernate.info/doc/nh/en/index.html#mapping-declaration-property (. Таблица 5.1 Стратегии доступа)