Я согласен с crunchdog - для всех, кроме самых простых веб-приложений, вы должны иметь плоскую форму бизнес-объектов специально для вашего уровня пользовательского интерфейса / представления. Иногда это называется классом View Model и обычно содержит не что иное, как несколько строковых свойств, из которых пользовательский интерфейс может получить и поместить непосредственно, не беспокоясь о проверке. (см. asp.net mvc )
С одной стороны, это делает слой пользовательского интерфейса чище и проще, позволяя приложить усилия к отображению данных, а не к обходу структур объектов, проверке и интерпретации нулей и т. Д.
Это также дает бизнес-уровню возможность выполнять проверку этих строковых значений, возвращая введенные значения, если они недействительны. Это может сэкономить на коде, когда, например, ваш сервер должен обрабатывать недопустимую дату в поле даты. Бизнес-уровень, распознавая недопустимые значения, может возвращать их точно в том виде, в котором они были получены, вместе с соответствующими сообщениями об ошибках. Если все, с чем вы имели дело, было объектами бизнеса / домена, то некоторые введенные значения могут не всегда соответствовать объектам, предназначенным для их хранения.
Это также может помочь иметь класс, предназначенный для отображения значений между объектами бизнес / домен и моделью объекта / представления пользовательского интерфейса. Это помогает четко разделить проблемы бизнес-уровня.