Что я должен вернуть из уровня пользовательского интерфейса в бизнес-уровень? - PullRequest
5 голосов
/ 19 февраля 2010

Я пишу приложение ASP.NET, в котором есть уровень пользовательского интерфейса, уровень бизнес-логики и уровень доступа к данным.Из уровня данных я возвращаю бизнес-объекты на уровень бизнес-логики и передаю их на уровень пользовательского интерфейса.Однако я не уверен, что делать, когда я хочу выполнить сохранение / вставку с данными из уровня пользовательского интерфейса.

Должен ли я создать бизнес-объект на уровне пользовательского интерфейса и перейти к бизнес-уровню илия должен создать его на бизнес-уровне?

большое спасибо

Ответы [ 4 ]

2 голосов
/ 24 февраля 2010

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

С одной стороны, это делает слой пользовательского интерфейса чище и проще, позволяя приложить усилия к отображению данных, а не к обходу структур объектов, проверке и интерпретации нулей и т. Д.

Это также дает бизнес-уровню возможность выполнять проверку этих строковых значений, возвращая введенные значения, если они недействительны. Это может сэкономить на коде, когда, например, ваш сервер должен обрабатывать недопустимую дату в поле даты. Бизнес-уровень, распознавая недопустимые значения, может возвращать их точно в том виде, в котором они были получены, вместе с соответствующими сообщениями об ошибках. Если все, с чем вы имели дело, было объектами бизнеса / домена, то некоторые введенные значения могут не всегда соответствовать объектам, предназначенным для их хранения.

Это также может помочь иметь класс, предназначенный для отображения значений между объектами бизнес / домен и моделью объекта / представления пользовательского интерфейса. Это помогает четко разделить проблемы бизнес-уровня.

0 голосов
/ 26 февраля 2010

Я обнаружил, что самым простым решением является передача объекта View Model из пользовательского интерфейса на бизнес-уровень по нескольким причинам.Наиболее очевидным является то, что проверка должна происходить на бизнес-уровне, поэтому создание бизнес-объекта в пользовательском интерфейсе нарушает принципы MVC.

Что еще более важно, если пользователь вводит неверные данные, бизнес-объект может (должным образом) не иметь возможности принимать эти данные.Однако вы не хотите выбрасывать введенные пользователем данные, поэтому объект View Model без проверки дает вам возможность сохранять и передавать введенные пользователем данные независимо от того, действительны они или нет.

0 голосов
/ 25 февраля 2010

Если вы не хотите чрезмерного кодирования бизнес-объекта, тогда вы правильно сделали при получении данных (когда вы возвращаете один и тот же бизнес-объект из DAL в BL в UI).

При сохранении данных вы можете передать эти объекты в качестве параметров слоя BL и \ или DAL. Вы можете либо передать текущий объект обратно, если связали его с элементом управления пользовательского интерфейса, либо создать новый экземпляр этого объекта и установить выполненные изменения.

Затем на вашем слое DAL просто прочитайте объект и сохраните изменения обратно в базу данных.

0 голосов
/ 19 февраля 2010

Я считаю, что лучше иметь объекты слоя пользовательского интерфейса, которые моделируют «реальные» бизнес-объекты. Этим объектам модели не нужно иметь всю информацию (ассоциации и тому подобное), которую имеют «реальные» бизнес-объекты. Тогда бизнес-уровень должен отвечать за преобразование бизнес-объектов в бизнес-объекты и обратно.

Для веб-приложений это особенно удобно, так как вам не нужно отправлять избыточные данные туда и обратно клиенту.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...