Как много логики вы должны поместить в класс пользовательского интерфейса?

Question

Я не уверен, было ли это задано или нет, но какую логику вы должны использовать в своих классах пользовательского интерфейса?

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

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

Есть ли хорошие правила о том, сколько логики вы используете в своих классах пользовательского интерфейса? Какие шаблоны мне следует искать, чтобы я не делал подобные вещи в будущем?

Answer 1

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

Иногда люди пытаются поместить даже это в бизнес-уровень. Например, можно иметь в своем BL:

if (totalAmount < 0)
     color = "RED";
else
     color = "BLACK";

А в пользовательском интерфейсе отображаем общее количество, используя цвет - что совершенно неверно. Должно быть:

if (totalAmount < 0)
     isNegative = true;
else
     isNegative = false;

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

Answer 2

Как можно меньше ... Пользовательский интерфейс должен иметь только логику, связанную с представлением. Теперь я предпочитаю иметь пользовательский интерфейс / просмотр

• просто поднять события (с подтверждающими данными) в PresenterClass, заявив, что что-то произошло. Пусть ведущий ответит на событие.
• есть методы для отображения / отображения данных, которые будут представлены
• минимальное количество проверок на стороне клиента, чтобы помочь пользователю сделать это правильно с первого раза ... (желательно, сделанным декларативно), отсеивая недопустимые входные данные еще до того, как он достигнет докладчика, например, убедитесь, что значение текстового поля находится в диапазоне a-b, установив свойства min и max.

http://martinfowler.com/eaaDev/uiArchs.html описывает эволюцию дизайна пользовательского интерфейса. Выдержка

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

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

Answer 3

Шаблон, который вы ищете, может быть Model-view-controller , который в основном отделяет DB (модель) от GUI (представление) и логики (контроллер). Вот Взятие Джеффа Этвуда на этом. Я считаю, что не следует фанатично относиться к какой-либо структуре, языку или шаблону - хотя тяжелые числовые вычисления, вероятно, не должны размещаться в графическом интерфейсе, хорошо выполнить некоторую базовую проверку входных данных и форматирование выходных данных.

Answer 4

Я предлагаю, чтобы интерфейс не включал какую-либо бизнес-логику. Даже не проверки. Все они должны быть на уровне бизнес-логики. Таким образом, вы делаете свой BLL независимым от пользовательского интерфейса. Вы можете легко конвертировать приложение Windows в веб-приложение или веб-сервисы и наоборот. Вы можете использовать объектные рамки, такие как Csla , чтобы достичь этого.

Answer 5

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

В нашей ситуации мы подошли к моменту, когда код формы автоматически генерируется из списка элементов управления, доступных в форме. В зависимости от типа элемента управления (bound text, bound boolean, bound number, bound combobox, unbound label, ...) мы автоматически генерируем набор процедур обработки событий (например, beforeUpdate и afterUpdate для текстовых элементов управления, onClick для меток и т. Д.), Которые запускают общий код, расположенный вне форма.

Этот код может затем выполнять общие действия (проверьте, можно ли обновить значение поля в событии beforeUpdate, , упорядочить набор записей по возрастанию / убыванию в onClick событие и т. д.) или конкретные обработки, основанные на имени формы и / или имени элемента управления (например, выполнение некоторой работы в событии afterUpdate, например вычисление значения элемента управления totalAmount из unitPrice и количество значения).

Наша система теперь полностью автоматизирована, и производство форм опирается на две таблицы: Tbl_Form для списка форм, доступных в приложении, и Tbl_Control для списка элементов управления, доступных в наших формах

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

Answer 6

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

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

Мало того, что это приводит к хорошему разделению слоев ... оно также спасает вас от раздувания кода.

Answer 7

Джеймс прав. Как правило, ваша бизнес-логика не должна делать никаких предположений относительно представления.

Что если вы планируете показывать результаты на разных носителях? Одним из них может быть черно-белый принтер. «КРАСНЫЙ» не порезал бы его.

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

Answer 8

Подтверждение ввода прилагается к элементу управления. Как письма, возраст, валидаторы даты с текстовыми полями