Бизнес / Доменный объект в ASP.NET

Question

Просто пытаюсь собрать мысли о том, что работает / не работает для манипулирования объектами Business / Domain через слой пользовательского интерфейса / презентации ASP.NET (2.0+). В частности, в классических прикладных ситуациях ASP.NET LOB, когда код ASP.NET взаимодействует напрямую с бизнес-уровнем. Я сталкиваюсь с этим типом дизайна довольно часто и задаюсь вопросом, что является идеальным решением (то есть, реализует определенный шаблон) и каково лучшее прагматическое решение, которое не потребует полного переписывания, когда не реализован «шаблон».

Вот пример сценария.

Одна страница ASP.NET, которая является страницей «Редактировать / Новая» для конкретного объекта «Бизнес / Домен», давайте в качестве примера рассмотрим «Лицо». Мы хотим редактировать информацию об имени и адресе на этой странице. Поскольку пользователь вносит изменения или вводит данные, в некоторых ситуациях форма должна быть отправлена ​​обратно, чтобы обновить себя. Например, при редактировании своего адреса они выбирают «Страна». После этого раскрывающийся список «Штат / регион» включается и обновляется соответствующей информацией для выбранной страны. По сути, это бизнес-логика (ограничение доступных выборов на основе некоторого зависимого поля), и эта логика обрабатывается бизнес-уровнем (помните, что это только один пример, есть много бизнес-ситуаций, когда логика более сложна во время обратной передачи - для Пример страховой отрасли при выборе определенных вещей диктует, какие другие данные необходимы / необходимы).

В идеале эта логика хранится только в объекте Business / Domain (т.е. без дублирования логики в коде ASP.NET). Я полагаю, что для этого необходимо повторно инициализировать объект Business / Domain и установить его состояние на основе текущих значений пользовательского интерфейса для каждой обратной передачи.

Например:

private Person person = null;

protected void Page_Load()
{
    person = PersonRepository.Load(Request.QueryString["id"]);

    if (Page.IsPostBack)
        SetPersonStateFromUI(person);
    else
        SetUIStateFromPerson(person);
}

protected void CountryDropDownList_OnChange()
{
    this.StateRegionDropDownList.Enabled = true;
    this.StateRegionDropDownList.Items.Clear();
    this.StateRegionDropDownList.DataSource = person.AvailableStateRegions;
    this.StateRegionDropDownList.DataBind();
}

Другие варианты, которые я видел, хранят бизнес-объект в SessionState, а не загружают его из хранилища (или базы данных) каждый раз, когда страница загружается обратно.

Мысли

Answer 1

Для очень простых вещей я бы не стал возиться с обычной публикацией назад, но использовал бы подход ajax. Например, если мне нужно получить список городов, у меня может быть метод страницы (или веб-служба), который с учетом состояния дает мне список городов.

Если ваши параметры зависят от широкого спектра параметров, то, что вы делаете, будет работать хорошо. Что касается хранения вещей в сессии, есть преимущества. Видны ли ваши объекты нескольким одновременно? Если так, то что происходит, когда Пользователь A и Пользователь B редактируют одинаково. Кроме того, каждый раз, когда вы загружаетесь, вы сохраняете базу данных? Что произойдет, если я редактирую свое имя, а затем выбираю страну, но теперь мой браузер падает. Вы обновили имя в БД?

Answer 2

С этой строкой я немного не согласен:

this.StateRegionDropDownList.DataSource = person.AvailableStateRegions;

Персона - это объект бизнеса / домена, но это не тот объект, который должен обрабатывать сопоставление состояния / региона (например), даже если именно там живет информация, необходимая для принятия решения.

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

Так что возможно (используя статическую функцию в классе State):

this.StateRegionDropDownList.DataSource = State.GetAvailableStateRegions(person, ipAddress);

Вследствие отделения проблем помощника пользовательского интерфейса от объекта домена Person этот стиль программирования имеет тенденцию быть намного «более тестируемым».

Answer 3

Я бы поместил ваш пример в корзину «Улучшения пользовательского интерфейса», а не в BL, чтобы убедиться, что записи правильные, это BL, но, по моему мнению, упрощение ввода данных - это пользовательский интерфейс.