Это будет пост не об архитектуре, а больше о MHO. Недавно меня попросили оценить архитектуру малых и больших интерфейсных решений. Существует большой ажиотаж вокруг фронтенд-разработки, и это побуждает многие компании создавать клиентские решения, не задумываясь о том, как их создавать. Одно из недоразумений, с которым я часто сталкиваюсь, — называть наличие библиотек JavaScript в решении архитектурой решения. Извините, но
Библиотеки JavaScript не являются интерфейсной архитектурой
Каждая библиотека JavaScript имеет дело с одним или несколькими аспектами вашего кода, такими как пространства имен/модули/пакеты в вашем серверном приложении. Будь то jQuery для взаимодействия с DOM, Backbone/Angular/Ember/Knockout для MV* и разделения ответственности, require.js для AMD или любой другой библиотеки JavaScript, все эти библиотеки решают некоторые распространенные проблемы.
Найдите минутку и задайте себе эти вопросы относительно ваших приложений JavaScript:
- Может ли ваше приложение масштабироваться?
- Если вы удалите один из модулей/функций на своей веб-странице, он сломается?
- Есть ли в вашем решении повторно используемые компоненты/функции?
- Части вашего приложения тесно связаны?
- Можно ли тестировать ваши модули/функции?
- Что происходит, когда модуль/функция находится в состоянии ошибки?
- И больше
Если вы ответили на эти вопросы, это может означать, что в вашем решении есть интерфейсная архитектура. Если вы не можете ответить на эти вопросы, у вас могут возникнуть проблемы с решением.
Создание больших и масштабируемых приложений JavaScript — сложная задача, и к ней нельзя подходить легкомысленно. Использование библиотек JavaScript помогает упростить задачу, но это не означает, что у вас есть архитектура. Хотелось бы услышать ваше мнение по теме.
Добавить комментарий
facebook linkedin twitter электронная почта
Первоначально опубликовано на сайте blogs.microsoft.co.il 24 апреля 2013 г.
