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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The separation of concerns is keeping the code for each of these concerns separate. Changing the interface should not require changing the business logic code, and vice versa.

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