Все это поток?

Question

Некоторые из моих недавних веб-проектов, над которыми я работал, используют движок потоков в качестве центральной абстракции в презентации и / или (более или менее) бизнес-уровне. Размышляя о своем опыте, я могу честно сказать, что я не фанат потоково-ориентированного подхода. Даже наоборот. Я вижу такие же симптомы в проектах, которые используют потоки в качестве центральной абстракции.

• Все является потоком. Вы не просто запускаете приложение, нет, вы «входите в основной поток», даже если оно просто показывает меню с огромным диспетчером за ним , Я не против потоков как таковых. Некоторые сценарии использования появляются везде, и их нужно включать в различные точки в других сценариях использования (LookupCustomer, ...), но для людей, ориентированных на поток все - это поток, даже вещи, которые .. . не течет.

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

• Файлы конфигурации. Большинство приложений используют какой-либо формат XML для объявления потоков и действий, сопровождающих изменения состояния. Язык, на котором написано приложение (скажем, Java, C #, Ruby, ...), вероятно, гораздо более богат и выразителен, чем когда-либо был формат XML. Зачем?

• Инкапсуляция разрыва потоков. Если вы дадите мне компонент, имеющий определенную встроенную логику потока, тогда поток должен быть частью компонента и не должен быть внешней абстракцией. Другими словами: поток является частью компонента, а компонент является автономным. Это деталь. Конечно, это может быть параметризовано и прочее, но компонент должен "просто работать". Люди, пишущие на Swing, GWT или любом другом толстом или многофункциональном интерфейсе, не заботятся о явных абстракциях потока. Почему мое веб-приложение должно иметь такое? Дайте мне блок-схему GMail.

• (Правка) Потоки процедурные. Если вы посмотрите на "богатые" шаблоны, такие как MVC, с событиями и всем остальным, потоки действительно бледны по сравнению. Вы используете современный и выразительный язык для реализации своего приложения, верно? Таким образом, вы можете делать лучше, чем жесткие "сделать то, то, то и то, и ..." в то время, когда в моде были перфокарты и сборщик.

Примерами сред, способствующих разработке, ориентированной на поток, являются Struts, BTT, Spring Webflow и JSF. Я также сталкивался с доморощенными двигателями, построенными на основе обычных сервлетов.

Это тоже интересная статья: http://chillenious.wordpress.com/2006/07/16/on-page-navigation/

Считаете ли вы (все еще) подход, ориентированный на поток, для (переднего плана) веб-приложения хорошей идеей?

Answer 1

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

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

• ... нас беспокоит способность нашего приложения обрабатывать непредвиденные данные или иметь дело с состояниями, которые мы не ожидали, если люди отклонятся от проторенного пути? Тогда это многое говорит о нашем техническом выборе для структуры валидации.

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

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

Основная проблема заключается в том, что потоки излишне увеличивают хрупкость, которая уже лучше абстрагируется другими механизмами. Например, для достижения правила, такого как «вам необходимо заполнить форму заказа, прежде чем подтвердить заказ» не делать рабочий процесс; иметь лучшую модель CustomerOrder, которая знает, когда у нее нет всей информации, необходимой для разрешения OrderConfirmation. Если вы попытаетесь пропустить вперед, ваша модель и контроллер должны позаботиться о неудачной проверке на следующем POST.

По сути, потоки извлекают разрозненные фрагменты каждого участвующего контроллера и собирают их в новый «контроллер потока», специфичный для каждого потока. Это не обязательно плохая идея, но она предполагает, что первоначальные контроллеры, возможно, взяли на себя слишком большую ответственность, если бы такой путь было так легко определить отдельно. Например, если у вас ранее были контроллеры OrderConfirmation, CustomerOrder и OrderCheckout, и вы думаете о потоке Order, чтобы связать все три вместе, то , о чем вы, вероятно, должны подумать, это Order контроллер вместо .

Answer 2

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

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

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

Концепция потоков, на мой взгляд, довольно хорошая, поскольку потоки, как правило, отражают варианты использования. Обработка данных в потоке или разговоре снимает с разработчика ответственность за их очистку, что, на мой взгляд, очень хорошая вещь. Это как разница между ручным управлением памятью и сборкой мусора. Это не только делает для меня меньше работы, но и исключает возможность появления ошибок, если я забуду очистить атрибуты. Одна вещь, которую я ненавидел в Struts, заключалась в том, что мне нужно было продублировать мой код очистки в нескольких действиях для обеспечения корректности. Гораздо проще просто перенести данные в вариант использования.

Потоки также представляют контекст для связанных действий и представлений. Если я посмотрю на файл struts-config или face-config, я смогу увидеть все виды правил навигации или сопоставлений действий, но у меня нет непосредственного контекста для умственной группировки связанных элементов. Я должен вручную проследить через конфигурацию, и даже тогда иногда я застреваю. В Struts мне нужно просмотреть конкретные веб-страницы, чтобы выяснить, какие действия можно вызывать из представления.

С помощью SWF я могу четко видеть все действия, представления и модели, связанные с потоком. С плагинами Eclipse я могу видеть это как диаграмму состояний. Даже если вы не используете eclipse, очень просто перевести определение потока в диаграмму состояний. Эти диаграммы полезны для меня, моего менеджера проекта, и практически для любого, кто хочет понять, как выполняется сценарий использования. Короче говоря, объединение связанных между собой вещей позволяет легче понимать и более мелкую кривую обучения. Это одна из причин, почему ООП так популярен. В веб-приложениях идея объединения этих элементов в единое целое просто кажется естественной.

Answer 3

Я думаю, что определение потоков полезно в веб-приложении. В ответ на ваши основные моменты:

Все есть поток.

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

Фрагментация

У вас есть несколько правильных замечаний, хотя у меня сложилось впечатление, что самым большим вкладом в это является дизайн DSL. Например, Spring WebFlow v2 представляет собой значительное улучшение по сравнению с SWF v1 с точки зрения читабельности и понятности.

Конфиг-файлы

Я категорически не согласен с этим. Я считаю, что xml - это лучший способ выразить этот код. Если подумать - управление контроллерами, представлениями, изменениями состояния и действиями - это на самом деле просто «конфигурация», а не «код». И xml (на мой взгляд) - лучший способ выразить конфигурацию. Просто подумайте о слове «Контроллер». Все, что делает контроллер, - это направляет и настраивает вещи - службы вызовов, возвратные представления и модели и т. Д. Нет необходимости в каком-либо богатстве или выразительности Java для определения того, что в основном является просто конфигурацией вашего веб-приложения.

Потоки разрыва инкапсуляции

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

Answer 4

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

Я думаю, что, возможно, вы действительно спрашиваете: «Почему большинство структур потоков так легко использовать?», Что естественно приводит к последующему вопросу «Что можно сделать, чтобы это исправить?».

Answer 5

Web 2.0 представляет серьезную проблему для представления о том, что «все есть поток». И когда уровень представления будет полностью перенесен на уровень клиента, мы вернемся на прочную и знакомую (с давних пор GUI) основу обработки на основе событий.

Answer 6

ИМХО, веб-приложения лучше всего разрабатывать как независимые модули, а не как модули, связанные потоком.

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

Конфигурации могут обрабатываться файлами XML или JSON.

Answer 7

Все есть поток

Все действительно поток. Компьютерные программы всегда были потоком и всегда будут потоком, содержащим эти процессы:

вход -> процесс -> выход

Шаблон проектирования MVC фактически соответствует этому ..

контроллер -> модель -> вид

Фрагментация

Ты прав. Но я думаю, что эта «проблема» может быть уменьшена благодаря хорошей поддержке IDE.

Конфиг-файлы

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

Потоки разрыва инкапсуляции

Я бы не согласился с этим. Вы можете создать черные ящики, используя потоки, а затем использовать эти черные ящики в других потоках.