Нужен совет относительно многоуровневого решения, разделения задач и т. д.

Question

У нас есть многоуровневое приложение или, по крайней мере, оно находится в процессе перехода к нему, разбитое следующим образом:

• Интерфейс (пользовательский интерфейс или интерфейс приложения, т.е.веб-сервис и т. д.)
• Бизнес-логика
• Доступ к данным

Чтобы сделать остальную часть этого вопроса более конкретной, я опишу конкретный случай.

У нас есть пользовательский интерфейс, за которым стоит объект-контроллер (уровень бизнес-логики).Этот контроллер взаимодействует с базой данных через другой объект (уровень доступа к данным).

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

• читаемое свойство, содержащее список доступных сотрудников на выбор
• свойство, доступное для чтения/записи, содержащее выбранного в данный момент сотрудника

Пользовательский интерфейс может прочитать список и использовать его для заполнения поля со списком.

В версии 1 этого приложения поле со списком содержит идентификационный номер сотрудника + имя сотрудника.

Все хорошо...

...до версии 1.1 исправлена ​​ошибка.Пользователь жалуется, что не может выбирать между Джимми Олсон и Джимми Олсон потому что приложение не позволяет ему достаточно легко узнать, что есть что.Он знает, что есть один Джимми в отделе продаж, а другой — в отделе разработки, поэтому исправление для этой версии 1.1 — просто добавить косую черту + название отдела в поле со списком.В версии 2 мы бы предпочли заменить поле со списком на поле со списком, которое поддерживает столбцы, удалив косую черту, но в версии 1.1 это выбрано, чтобы минимизировать риск дальнейших ошибок.

Другими словами, поле со списком будет содержать:

• 1 - Джимми Олсон/Продажи
• 2 – Джимми Олсон/Развитие
• • другие люди

Однако в коде пользовательского интерфейса нет кода SQL или какого-либо способа получить доступ к этому отделу, и поэтому нам приходится идти к контроллеру и просматривать там код.Контролеру не нужен отдел, и если честно, ему даже не нужно имя сотрудника, достаточно идентификационного номера, поэтому в контролере нет ничего, что бы что-то просило или делало с отделом.Поэтому нам нужно спуститься на уровень доступа к данным и изменить там SQL.

Это решение откровенно пахнет.

Если к этому контроллеру имеется несколько интерфейсов с разными требованиями, у нас есть три возможных решения:

1. Измените уровень доступа к данным, чтобы удовлетворить (растущие/разнообразные) потребности нескольких интерфейсов (на расстоянии двух уровней). Это означает, что все интерфейсы, возможно, получат все необходимые им данные, но они также получат все данные, необходимые для любого других интерфейсов
2. Добавьте что-то, что позволит пользовательскому интерфейсу сообщать уровню доступа к данным (все еще на расстоянии 2 уровней), что ему нужно.
3. Каким-то образом заставить уровень пользовательского интерфейса получать необходимые данные, не меняя ни контроллер, ни уровень доступа. Это звучит так, будто нам где-то нужно больше кода доступа к данным.

Ни одно из вышеперечисленных решений не приносит удовлетворения.

Меня интересует, неужели мы совсем сбились с курса?Как бы вы это сделали?Есть ли четвертое и пятое решение ниже трех выше?

По этому вопросу: Разделение интересов, принятый ответ содержит эту цитату:

Разделение задач подразумевает сохранение кода для каждой из этих задач отдельно.Изменение интерфейса не должно требовать изменения кода бизнес-логики, и наоборот.

Означает ли это просто, что весь уровень контроллера/доступа к данным должен предоставить нам все, что ему нужно для выполнения своей работы (т.идентификационные номера сотрудников), а затем пользовательский интерфейс должен обратиться к базе данных и запросить дополнительную информацию о эти конкретные сотрудники?

Answer 1

Насколько я понимаю, у вас есть две возможности:

1. Отправьте нижние слои вверх. всеИнформация, которую они имеют о человеке, возможно, в качестве документа XML, хотя многие потребители этой информации не нуждаются в этом.
2. Предоставьте API для уровней более высокого уровня, чтобы сверлить и получить необходимую им информацию.Таким образом, в случае, если вы даете, есть метод, который интерфейс может попросить бизнес -уровня спросить уровень базы данных для департамента с учетом идентификатора пользователя.

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