Обновить

Разработка архитектуры вашего приложения в Ext JS 4

JavaScript
Автор оригинала: Tommy Maintz
Масштабируемость, удобство обслуживания и гибкость приложений во многом определяются качеством архитектуры приложения. К сожалению, архитектуру приложения часто относят к второстепенным факторам. Концепты и прототипы превращаются в массовые приложения, а примеры кода копируются и вставляются «как есть» в фундамент многих приложений. Вы можете захотеть двинуться лёгким путём из-за быстрого прогресса, который вы видите в начале проекта.

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

Организация кода



image
Архитектура приложения описывает как структуру и последовательность организации кода, так и фактические классы и используемые библиотеки. Создание хорошей архитектуры открывает ряд важных преимуществ:
  • Каждое приложение пишется всегда одинаково, таким образом, Вы должны выучить эту структуру только один раз;
  • Легко поделиться кодом между приложениями, поскольку все они работают одинаково;
  • Вы можете использовать инструменты построения Ext JS для создания оптимизированных версий приложений для промышленного использования.
В Ext JS 4, мы определили соглашения, которые необходимо учесть при создании приложений — в первую очередь, единую структуру каталогов. Эта простая структура организует все классы в каталоге app, который, в свою очередь, содержит подпапки, чтобы организовать пространства имен ваших моделей, представлений, контроллеров и хранилищ.

Хотя Ext JS 4 предлагает передовой опыт того, как структурировать ваше приложение, есть возможность изменить предложенные нами соглашения для именования файлов и классов. Например, вы можете решить, что в проект необходимо добавить суффикс к контроллерам «Controller», например, «Users» становятся «UsersController». В этом случае не забывайте всегда добавить суффикс не только к имени класса, но и к имени соответствующего файла. Важно то, что вы должны определить эти соглашения, прежде чем начать писать приложение, и последовательно следовать им. Наконец, хотя вы можете именовать свои классы, как вам угодно, мы настоятельно рекомендуем следовать нашему соглашению для имен и структуры папок (контроллеры, модели, хранилища, представления). Это будет гарантировать, что вы получите оптимизированный код с помощью наших SDK Toolsbeta.

Достижение баланса


Разделение пользовательского интерфейса приложения на представления является хорошей точкой для старта. Часто, вы получаете зарисовки и макеты пользовательского интерфейса, созданные дизайнерами. Представьте, что нас просят воссоздать (очень привлекательное) приложение Pandora с помощью Ext JS, и нам предоставляются следующие макеты от нашего дизайнера интерфейсов:

image

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

image

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

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

image

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

Правильный баланс достигается, когда мы можем легко изменить расположение представлений на странице без необходимости рефакторить их каждый раз. Например, мы хотим, чтобы рекламный блок (Ad) был отдельным представлением, чтобы мы могли легко переместить его, или даже удалить его позднее.

image

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

Модели


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

image

Мы решили использовать только две модели — Трек (Song) и Радиостанция (Station). Мы могли бы определить еще две модели, для исполнителя и альбома. Однако, как и с представлениями, мы не хотим быть слишком подробными при определении наших моделей. В этом случае, мы не должны отделять информацию об исполнителе и об альбоме, потому что приложение не позволяет пользователю выбрать определенную песню по заданному исполнителю. Вместо этого данные организованы по радиостанциям, Трек является центральной фигурой, — исполнитель и альбом являются свойствами трека. Это означает, что мы можем объединить данные трека, исполнителя и альбома в одной модели. Это значительно упрощает работу с данными для нашего приложения. Она также упрощает API, которые мы должны реализовать на серверной стороне, потому что у нас нет для загрузки отдельных артистов или альбомов. Подводя итог для этого примера, — мы будем иметь только две модели, музыкального трека и радиостанции.

Хранилища


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

image

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

Контроллеры


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

image

Здесь мы имеем два основных контроллера — SongController и StationController. Ext JS 4 позволяет иметь контроллер, который может управлять несколькими представлениями одновременно. Наш StationController будет обрабатывать логику как для создания новых станций, так и для загрузки любимых радиостанций пользователя в представление StationsList. SongController позаботится об управлении представлением SongInfo, и хранилищем RecentSong, а также о таких действиях пользователя, как like, dislike, остановка или пропуск трека. Контроллеры могут взаимодействовать друг с другом путем генерации событий и подписки на события приложения. Хотя мы могли бы создать дополнительные контроллеры, один для управления воспроизведением, а другой для поиска станции, я думаю, что мы нашли хорошее разделение обязанностей.

Семь раз отмерь, один раз отрежь


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

Автор: Томми Майнц.

Томми Майнц ведет разработку Sencha Touch. С обширные знаниями объектно-ориентированного JavaScript и знанием индивидуальных особенностей мобильных браузеров он раздвигает границы того, что возможно, в рамках мобильных браузеров. Томми приносит уникальную точку зрения и амбициозную философию создания привлекательных пользовательских интерфейсов. Его внимание к деталям ведет к осуществлению желания обрести идеальный каркас для разработчиков.
Следуйте за Томми на Твиттере
Теги:senchaext.jsархитектура приложений
Хабы: JavaScript
Рейтинг +35
Количество просмотров 3,4k Добавить в закладки 90
Комментарии
Комментарии 30

Похожие публикации

Cистемный архитектор/System architect
от 250 000 до 350 000 ₽C-Executives LLCМожно удаленно
Javascript разработчик
от 130 000 до 180 000 ₽ArtezioНижний Новгород
Разработчик приложений Flutter
от 200 000 ₽HighTeamМоскваМожно удаленно
Javascript разработчик
от 160 000 до 220 000 ₽ArtezioМосква
JavaScript Software Engineer
от 3 000 до 5 500 $XPOWERОдессаМожно удаленно

Лучшие публикации за сутки