В настоящее время мы используем NHibernate для отображения бизнес-объектов в таблицы базы данных. Указанные бизнес-объекты обеспечивают соблюдение бизнес-правил: установленные методы доступа сразу генерируют исключение, если контракт для этого свойства нарушен. Кроме того, свойства обеспечивают связь с другими объектами (иногда двунаправленными!). Хорошо, всякий раз, когда NHibernate загружает объект из базы данных (например, когда вызывается ISession.Get (id)), для доступа к данным в объекте используются установленные методы доступа сопоставленных свойств.
Что хорошо, так это то, что средний уровень приложения обеспечивает выполнение бизнес-логики. Что плохо, что базы данных нет. Иногда дерьмо попадает в базу данных. Если дерьмо загружается в приложение, оно освобождается от ответственности (выдает исключение). Иногда это должно быть под залог, потому что он ничего не может сделать, но что, если он может продолжать работать? Например, инструмент администратора, который собирает отчеты в реальном времени, подвергается высокому риску ненужного сбоя вместо того, чтобы позволить администратору даже устранить (потенциальную) проблему.
У меня сейчас нет примера для меня, но в некоторых случаях разрешение NHibernate использовать свойства "парадной двери", которые также обеспечивают соблюдение отношений (особенно биди), приводит к ошибкам.
Каковы лучшие решения?
В настоящее время я создам «заднюю дверь» только для 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, которое разрывает все существующие запросы, используя «Blah» (обычная проблема при программировании со строками).
Кто-нибудь решил эти проблемы?!