UI Layer Abstraction

Question

Я успешно работал с абстрагированием слоев данных и бизнес-уровней. Но недавно коллега упомянул об абстрагировании уровня пользовательского интерфейса между пользовательским интерфейсом и бизнес-уровнем. Однако я не могу понять это. Я не могу представить, как этот уровень пользовательского интерфейса будет отличаться от бизнес-уровня. Я вытащил достаточно очков для статей и, кажется, не нашел большой помощи. Может кто-нибудь сказать мне простой пример?

Answer 1

Я нашел серию статей Джереми Миллера Build Your Own CAB очень информативной в прошлом. Он описывает множество вариаций в семействе моделей Model-View-Controller. Это отличное чтение.

Answer 2

Я читал о MVC, MVP и диалоговом окне Humble (я выдернул волосы). Коллега, который упомянул уровень пользовательского интерфейса, не смог дать мне очень хороший пример того, как он отличается от бизнес-уровня. И когда его спросили, он сказал, что это не MVC / MVP. Поэтому я подумал, что спросить около

Answer 3

Здесь есть несколько вариантов.

1. MVC

   Вам необходимо отделить представление от модели и контроллера. Самый простой способ представить, почему вы это сделали, - это если бы у вас была та же Модель и Контроллер, для которых вы хотели представить разные представления - представление веб-сайта, представление автономного приложения, представление веб-службы, представление мобильного телефона, ваши юнит-тесты и т. д. Поэтому вам не нужна логика в вашем коде представления. То есть, в Java нет манипуляций с моделью внутри ваших ActionListeners и другого кода GUI - вместо этого вы перемещаете это в класс контроллера, а обработчик View просто выполняет проверку ввода, форматирование вывода и общается с классом контроллера.

   Многие представления написаны на основе подхода, ориентированного на представления. У вас есть свой графический интерфейс. Что-то происходит, и вы реагируете на это, делаете что-то и обновляете графический интерфейс по мере необходимости. Поэтому легко связать свою бизнес-логику и модель очень тесно с представлением.

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

2. Веб-форма сбора данных (или серия веб-форм)

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

3. Интерфейс, сгенерированный из модели

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

4. Что-то еще ...

Answer 4

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

Это не отвечает об отдельном «уровне пользовательского интерфейса» между пользовательским интерфейсом и моим сервисным уровнем. Возможно, это связано с тем, что HTML и код разделены (то есть код ASP.Net может рассматриваться как уровень пользовательского интерфейса). Нет ничего хуже (в изменении / отладке веб-приложений), чем необходимость изменения глобальных настроек HTML, когда разметка строится по частям из тысячи различных функций. HTML должен быть только в файлах HTML с минимальным количеством сценариев, необходимых для связи их с классами.

Answer 5

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

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

Попробуйте поискать в Google некоторые известные шаблоны пользовательского интерфейса:

MVC MVP Диалоговое окно «Скромный»