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

Question

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

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

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

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

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

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

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

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

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

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

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

• 1 - Джимми Olson/Менеджер по продажам
• 2 - Джимми Olson/Разработка
• • других людей

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

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

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

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

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

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

За этот вопрос: Separation of Concerns, принятый ответ содержит эту цитату:

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

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

Answer 1

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

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

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