Не пустые ограничения в объектах POCO

Question

Я сейчас пишу финансовую заявку, и у нас довольно стандартная таблица клиентов. Он состоит из множества обязательных полей и некоторых необязательных, таких как Cell / Fax и т. Д. Я использую NHibernate в качестве ORM и у меня все сопоставления правильные. Это уже работает.

Мне просто интересно, как я "выражаю" в коде, что поле не пусто без комментариев? У меня есть файлы hbm.xml, которые документируют это, но довольно неловко смотреть на них для таких вещей.

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

Как видите, я хочу, чтобы сотовая связь и факс были необязательными, а телефон - обязательным. Все они являются просто составными сопоставлениями, поэтому файл сопоставления просто указывает, что отдельные элементы каждого должны быть ненулевыми, но я не хочу постоянно проверять Person.Cellular! = Null, чтобы избежать исключения NullReferenceException.

Answer 1

Создание свойств notnull только для чтения и запись в них через открытый конструктор. Сделать конструктор по умолчанию защищенным или закрытым.

public class DomainObject{
private string nnp;
protected DomainObject(){}
public DomainObject(string nnp){
this.nnp = nnp;
}
public string NotNullProp {get {return nnp;}}
public string NullableProp {get;set;} 
}

Answer 2

Есть несколько способов сделать это в зависимости от вашего поведения POCO и стиля кодирования. Во-первых, вы можете использовать обнуляемые типы, чтобы выразить, что это поле является обнуляемым, и поэтому будет подразумеваться, что остальные не обнуляются. В качестве альтернативы вы можете ввести тип значения Phone в качестве типа для свойства Phone POCO, которое вы проиллюстрировали, подразумевая, что, поскольку это не примитивный тип, он «более важен» - это также позволит вам инкапсулировать проверку номера телефона в классе сам по себе.

По моему мнению, чтобы быть настоящим POCO-объектом, ему не нужно беспокоиться об основополагающей обнуляемости в таблице базы данных, в которой он хранится ... он должен фактически иметь типы проверки и значения, которые выражают его поведение как отдельную сущность ; таким образом, прежде чем попасть в NHibernate, он уже находится в действительном состоянии.