Подход к разработке: пользовательский интерфейс или модель домена?

Хотя я никогда ничего не делал с помощью Smalltalk, мое недолгое времяпровождение с ним определенно оставило свой след. Единственный способ описать опыт - это MVC, каким он должен был быть. По сути, вся тяжелая работа для вашего приложения выполняется в бизнес-объектах (или доменной модели, если вы склонны к этому). Стандартные элементы управления каким-либо образом связаны с бизнес-объектами. Например, текстовое поле сопоставляется с полем объекта (само поле является объектом, так что это легко сделать). Кнопка будет привязана к методу. Все это делается с помощью очень простого и естественного API. Нам не нужно думать о связывании объектов и т. Д. Это просто работает.

Тем не менее, во многих более новых языках и API вы вынуждены мыслить извне. Сначала с C ++ и MFC, а теперь с C # и WPF, Microsoft получила свой мир разработчиков, подключенный к сборщикам GUI, где вы создаете свое приложение, реализуя обработчики событий , Разработка Java Swing не так уж отличается, только вы пишете код, чтобы сами создавать экземпляры элементов управления в форме. Для некоторых проектов модель доменного имени может даже никогда не существовать - только обработчики событий. Я был в и вокруг этой модели для большей части моей карьеры.

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

Многие разработчики, с которыми я работаю, видят ценность в подходе Smalltalk и пытаются внедрить этот подход в среду VisualStudio. WPF имеет некоторые функции динамического связывания, которые делают это возможным; но есть ограничения. Неизбежно, некоторый код, который принадлежит модели предметной области, заканчивается в классах GUI.

Итак, каким образом вы разрабатываете / разрабатываете свой код? Почему?

• GUI первый. Взаимодействие с пользователем имеет первостепенное значение.
• Домен первый. Мне нужно убедиться в правильности системы, прежде чем мы добавим на нее пользовательский интерфейс.

Есть плюсы и минусы для любого подхода. Доменная модель вписывается туда с хрустальными соборами и пирогом в небе. GUI подходит там быстро и грязно (иногда очень грязно).

И для дополнительного бонуса: как вы убедитесь, что код поддерживается?

ни

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

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

  +------+
  |  UI  | <- Think about how to make an effective user interface
  +------+
      |
      |
 +----------+
 | Contract | <--- This part over here is really REALLY important, man!
 +----------+
      |
      |
+--------------+
| Domain model | <- Think about what the user needs
+--------------+ 

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

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

Неважно, с какой стороны вы начинаете сначала ... важно то, что у вас есть четкое разделение проблем на месте. Этот контракт в середине в значительной степени определяет приложение или систему под рукой. Подумайте об этом, прежде чем идти снизу вверх или сверху вниз .

Домен первый. Мне нужно убедиться в правильности системы, прежде чем мы добавим на нее пользовательский интерфейс.

Больше ничего нельзя заставить работать - кроме как в простых случаях.

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

Нельзя сказать, что пользовательский интерфейс сначала обречен на неудачу - если модель достаточно проста, пользовательский интерфейс может быть построен в первую очередь с уверенностью, что модель в конце концов будет работать нормально.

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

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

Это действительно зависит от приложения под рукой.

Если вы создаете закрытое клиент-серверное приложение, тогда достаточно одного из подходов; поскольку вы собираетесь манипулировать задним концом, чтобы удовлетворить потребности передних концов, неизбежно.

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

Часто в последнее время в связи с небольшим повторением циклов разработки (Scrum, Kanban и т. Д.) Внешний и внутренний интерфейсы выполняются параллельно. Речь идет о предоставлении того, что вам нужно для данной итерации; не обращая внимания на сборку, если нам нужен подход . При параллельном подходе оба конца остаются намного ближе на протяжении всего процесса разработки, что может устранить необходимость в постоянных изменениях, когда передний конец и задний конец объединяются. Это мой предпочтительный подход, когда это возможно.

Ты упомянул...

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

Не уверен, что вы подразумеваете под некоторыми ? WPF и SL оба известны своей связывающей функциональностью. Это бесконечно. Если вы вынуждены размещать код в своем View в WPF-приложении на основе MVVM, тогда нужно что-то решать. Прикрепленное поведение - это один из способов реализации поведения без привязки к событиям в представлении, а также множество других подходов, обеспечивающих чистоту вашего представления.

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

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

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

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

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

Я помню, как однажды даже ведущий разработчик закричал на меня, что архитектура Document / View считалась устаревшей, когда я предположил, что нам нужно прекратить связывать весь наш бизнес-код с пользовательским интерфейсом (и в то время мы использовали win32 в C ++, так что это программирование методом перетаскивания мышью). вещь даже не была нашей проблемой). Я был просто ошеломлен.

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

Как разработчик C #, я определенно не думаю, что вы работаете снаружи. Вообще-то, я предпочитаю делать сначала модель предметной области.

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

Конечно, домен первый!

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

Это не значит, что Smalltalkers не работали над этими двумя одновременно, но когда ваш GUI не смог реализовать бизнес-логику, вы обычно сначала исправляли модель предметной области, а не помещали особые случаи в ваш GUI.