Архитектура современных приложений

Архитектура современных Web-приложений

Алексей Федоров, Наталия Елманова

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

Следующим этапом развития Web стало появление понятия приложений, которые базировались на таких интерфейсах, как CGI (или FastCGI), а в дальнейшем — на ISAPI. Common Gateway Interface (CGI) — это стандартный интерфейс с серверами, позволяющий выполнять серверные приложения, вызываемые через URL. Входной информацией для таких приложений служило содержимое HTTP-заголовка (и тело запроса при использовании протокола POST). CGI-приложения генерировали HTML-код, который возвращался браузеру. Основной проблемой CGI-приложений было то, что при каждом клиентском запросе сервер выполнял CGI-программу в реальном времени, загружая ее в отдельное адресное пространство.

Появление Internet Server API (ISAPI) позволило не только решить проблемы производительности, которые возникали с CGI-приложениями, но и предоставить в распоряжение разработчиков более богатый программный интерфейс. ISAPI DLL можно было ассоциировать с расширениями имен файлов через специальную мета-базу. Эти два механизма (CGI и ISAPI) послужили основой создания первого типа Web-приложений, в которых, в зависимости от каких-либо клиентских действий, выполнялся серверный код. Таким образом, стала возможной динамическая генерация содержимого Web-страниц и наполнение Web перестало быть чисто статическим.

Интерфейс ISAPI — это особенность Microsoft Internet Information Server (о последней версии этого продукта вы можете прочесть в статье «Internet Information Services 6.0». ISAPI-приложения представляют собой динамические загружаемые библиотеки (DLL), которые выполняются в адресном пространстве Web-сервера. У других Web-серверов через некоторое время также появилась возможность выполнять приложения, реализованные в виде библиотек. В случае Web-серверов Netscape этот программный интерфейс назывался NSAPI (Netscape Server API). У довольно популярного Web-сервера Apache также имеется возможность выполнять Web-приложения, реализованные в виде библиотек; такие библиотеки называются Apache DSO (Dynamic Shared Objects).

Естественно, что при использовании как CGI-, так и ISAPI-приложений разработчики в основном решали одни и те же задачи, поэтому естественным шагом стало появление нового, высокоуровневого интерфейса, который упростил задачи генерации HTML-кода, позволил обращаться к компонентам и использовать базы данных. Таким интерфейсом стала объектная модель Active Server Pages (ASP), построенная на основе ISAPI-фильтра.

Основной идеей ASP с точки зрения создания интерфейса приложения является то, что на Web-странице присутствуют фрагменты кода, который интерпретируется Web-сервером и вместо которого пользователь получает результат выполнения этих фрагментов кода.

Вскоре после появления ASP были созданы и другие технологии, реализующие идею размещения внутри Web-страницы кода, выполняемого Web-сервером. Наиболее известная из них на сегодняшний день — технология JSP (Java Server Pages), основной идеей которой является однократная компиляция Java-кода (сервлета) при первом обращении к нему, выполнение методов этого сервлета и помещение результатов выполнения этих методов в набор данных, отправляемых в браузер.

Новейшая версия технологии Active Server Pages — ASP .NET, являющаяся ключевой в архитектуре Microsoft .NET Framework. С помощью ASP .NET можно создавать Web-приложения и Web-сервисы, которые не только позволяют реализовать динамическую генерацию HTML-страниц, но и интегрируются с серверными компонентами и могут использоваться для решения широкого круга бизнес-задач, возникающих перед разработчиками современных Web-приложений.

В общем случае клиентом Web-сервера может быть не только персональный компьютер, оснащенный обычным Web-браузером. Одновременно с широким распространением мобильных устройств появилась и проблема предоставления Web-серверами данных, которые могут быть интерпретированы этими устройствами. Поскольку мобильные устройства обладают характеристиками, отличными от характеристик персональных компьютеров (ограниченным размером экрана, малым объемом памяти, а нередко и невозможностью отобразить что-либо, кроме нескольких строк черно-белого текста), для них существуют и другие протоколы передачи данных (WAP — Wireless Access Protocol) и соответствующие языки разметки (WML — Wireless Markup Language, СHTML — Compact HTML и т.п.). При этом возникает задача передачи данных на мобильное устройство в соответствующем формате (и для этой цели существуют специальные сайты), либо, что представляется более удобным, происходит опознание типа устройства в момент его обращения к серверу и преобразование исходного документа (например, в формате XML) в формат, требующийся данному мобильному устройству (например, с помощью XSLT-преобразования).

Другим способом поддержки различных типов клиентов является создание «разумных» серверных компонентов, которые способны генерировать различный код в зависимости от типа клиента. Такой подход, в частности, реализован в Microsoft ASP .NET.

Другим направлением развития клиентских частей Web-приложений стало размещение некоторой части логики приложения (такой как проверка корректности вводимых данных) в самом Web-браузере. В частности, современные Web-браузеры способны интерпретировать скриптовые языки (VBScript, JavaScript), код на которых, как и ASP-код, внедряется в Web-страницу, но интерпретируется не Web-сервером, а браузером и соответственно выполняется на клиентском устройстве. Кроме того, современные браузеры способны отображать и выполнять Java-аплеты — специальные Java-приложения, которые пользователь получает в составе Web-страницы, а некоторые из браузеров могут также служить контейнерами для элементов управления ActiveX — выполняющихся в адресном пространстве браузера специальных COM-серверов, также получаемых в составе Web-страницы. И в Java-аплетах, и в элементах управления ActiveX можно реализовать практически любую функциональность.

Отметим, что с ростом объема используемых данных и числа посетителей Web-сайтов возрастают и требования к надежности, производительности и масштабируемости Web-приложений. Следующим этапом эволюции подобных приложений стало отделение бизнес-логики, реализованной в Web-приложении, а нередко и сервисов обработки данных и реализации транзакций от его интерфейса. В этом случае в самом Web-приложении обычно остается так называемая презентационная часть, а бизнес-логика, обработка данных и реализация транзакций переносятся в сервер приложений в виде бизнес-объектов. В зависимости от типа сервера приложений подобные бизнес-объекты могут быть выполняющимися самостоятельно COM-серверами, CORBA-серверами, а также объектами COM+, выполняющимися с помощью служб компонентов Windows 2000, или объектами EJB (Enterprise Java Beans), исполняемыми сервером приложений, поддерживающим спецификацию J2EE (Java 2 Enterprise Edition). В качестве механизма доступа к данным подобные объекты могут использовать OLE DB, ODBC, JDBC (это зависит от того, как реализован бизнес-объект).

Нередко подобные бизнес-объекты предоставляют доступ к данным корпоративных информационных систем либо реализуют какую-либо часть их функциональности. Нередко они позволяют, например, интегрировать Web-сайт с CRM-системами (CRM — Customer Relationship Management — приложения для автоматизации и повышения эффективности процессов, направленных на взаимоотношения с клиентами, таких как обработка заказов, маркетинг, обслуживание) или с ERP-системами (ERP — Enterprise Resource Planning — приложения для автоматизации управления внутрихозяйственными процессами предприятия, такими как производство, финансы, снабжение, управление персоналом и др.), сохраняя в корпоративных системах сведения о посетителях сайта и предоставляя потенциальным клиентам сведения об имеющейся продукции для осуществления заказов.

Поскольку современный Internet — это не столько средство демонстрации присутствия компании на рынке или инструмент маркетинга, сколько инструмент ведения бизнеса, достаточно важными становятся задачи реализации организации через Internet таких взаимоотношений с клиентами, как продажа товаров и услуг. И здесь довольно важными становятся решения для электронной коммерции типа «предприятие—клиент» (B2C — business-to-consumer). Не менее важными становятся и задачи интеграции Web-приложений c данными и приложениями партнеров с целью реализации схемы «предприятие—предприятие» (B2B — business-to-business), позволяющей заключать торговые сделки между предприятиями, обмениваться каталогами товаров, проводить аукционы, создавать электронные торговые площадки.

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

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

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

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

Решение многих описанных выше задач, возникающих при создании современных Web-приложений, теперь начинает возлагаться на Web-сервисы — не зависящие от платформы, объектной модели и клиента программные компоненты, которые можно вызывать из клиентских Web-приложений (а также из самих Web-сервисов) через основанный на протоколе HTTP и языке XML протокол SOAP. Для описания Web-сервисов используется XML-подобный язык WSDL, а для организации реестров Web-сервисов, в которых разработчики и компании могут искать необходимые им сервисы, а также публиковать данные о своих сервисах — интерфейс UDDI. Более подробно о технологиях, лежащих в основах Web-сервисов, можно прочитать в статье «Технологии для Web-сервисов», опубликованной в этом номере.

Поддержка Web-сервисов стала одним из главных стратегических направлений для многих компаний, специализирующихся на выпуске серверов приложений, систем управления базами данных и средств разработки приложений. В публикуемой в данном номере статье «Платформы и средства создания Web-сервисов» мы подробно рассматриваем поддержку Web-сервисов в продуктах таких компаний, как BEA Systems, Borland, Hewlett-Packard, IBM, Microsoft, Oracle, Sun Microsystems и Sybase.

Заключение

В этой статье мы рассмотрели эволюцию архитектуры Web-решений, начиная от простейших хранилищ HTML-страниц и заканчивая современными корпоративными решениями, интегрированными с корпоративными информационными системами и информационными системами партнеров. Попутно мы обсудили задачи, возникающие на каждом этапе развития Web-приложений и технологии, решающие эти задачи, включая CGI, ISAPI, ASP, JSP, применение скриптовых языков, ActiveX и Java-аплетов, взаимодействие с серверами приложений и с базами данных, применение COM, CORBA и EJB, создание и применение Web-сервисов, основанных на XML. Мы также рассмотрели средства создания таких решений, а именно: корпоративные порталы, средства управления информационным наполнением Web-сайтов, приложения для электронной коммерции.

Архитектура приложения

Стоимость архитектуры приложения

сроки выполнения : 21 день

От чего зависит цена

По вашему желанию,
цена будет снижена , если:

Заказать годовое сопровождение

Сократить объем работ
(меньше концептов)

Увеличить сроки выполнения

Проектирование архитектуры приложения

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

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

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

1. Эффективность: приложение выполняет поставленные задачи и выполняет функции в любых условиях. Система производительна, надежна и справляется со всеми нагрузками.
2. Гибкость: выбранное решение легко менять, и ошибок становится меньше. Можно изменить один элемент, и это не станет фатальным для других составляющих.
3. Расширяемость: в приложение можно добавлять сколько угодно функций, если потребуется.
4. Масштабируемость: время на разработку и дополнение уменьшается. Хорошая архитектура позволяет направить разработку в несколько параллельных потоков.
5. Тестируемость: приложение легко тестируется, а значит, уменьшается число ошибок и увеличивается его надежность.
6. Повторное использование: элементы и структуру можно использовать в других проектах.
7. Понятность: код должен быть понятен как можно большему количеству людей. Над приложением работает много людей. Хорошая архитектура позволяет новичкам быстро разобраться в проекте.

Мы знаем, как сделать хорошую архитектуру! Обращайтесь в агентство KOLORO. Проектирование мобильных приложений – наша специализация.

Как происходит проектирование приложений

Проектирование мобильных или веб-приложений может проходить тремя способами, в зависимости от задач проекта:

• монолитный;
• модульный;
• сервис-ориентированный.

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

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

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

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

Мы знаем, как ускорить проектирование интерфейса приложения! Обращайтесь к специалистам агентства KOLORO.

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

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

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

Сколько стоит час работы архитектора приложения?

Проектирование приложения может оцениваться «пакетом» или по часовой ставке. Диапазон расценок варьируется от 10 000 до 200 000 рублей, а в среднем проектирование обычно оценивается в 100 000 рублей.

Часовая ставка меняется в диапазоне от 1 000 до 2 000 рублей. Чаще всего встречается сумма 1 500 – 1 800 рублей за час.

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

В обязанности архитектора приложения входит:

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

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

В наших силах – дизайн, проектирование приложений, создание уникального пользовательского опыта. Обращайтесь к разработчикам агентства KOLORO!

Из чего состоит архитектура мобильных приложений

Архитектура зависит от выбранного типа приложения.

Мобильное native-приложение – это программа для iOS, Android и других платформ. Native означает, что приложение создано для одной платформы. Плюс – эффективность благодаря соответствию всем требованиям выбранной категории устройств. Минус – приложение плохо работает на других платформах.

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

Гибридное приложение совмещает в себе элементы первых двух типов. Проектирование андроид приложения и программ для iOS в последнее время часто выбирает этот тип.

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

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

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

Визуальное проектирование приложений

Визуальное проектирование (RAD) – современный инструмент, ускоряющий разработку приложений. Быстрота достигается за счет графических средств, с помощью которых разработчики создают программы. Разработчики рисуют новое приложение в специальных программах. Сразу визуально видны схемы базы данных, интерфейсы, эскизы экранов.

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

Проектирование java приложений обходится дешевле, чем создание программ на языках C и С++. Java – доступный и легкий для понимания язык, к нему предлагается множество сервисов и библиотек. Наши специалисты смогут создать быструю и надежную программу с экономичным использованием компьютерных ресурсов – и это будет дешевле, чем проект на С.

Проектирование, разработка мобильных приложений – мы можем все. И это не преувеличение. Обращайтесь к специалистам нашего агентства KOLORO!

Краткий обзор 10 популярных архитектурных шаблонов приложений

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

Что такое архитектурный шаблон?

По материалам Википедии,

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

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

1. Многоуровневый шаблон

2. Клиент-серверный шаблон

4. Каналы и фильтры

5. Шаблон посредника

6. Одноранговый шаблон

1. Многоуровневый шаблон

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

Чаще всего в общих информационных системах встречаются следующие 4 слоя:

· Слой представления (также известен как слой пользовательского интерфейса)

· Слой приложения (также известен как слой сервиса)

· Слой бизнес-логики (также известен как уровень предметной области)

· Слой доступа к данным (также известен как уровень хранения данных)

Использование

· Общие десктопные приложения.

2. Клиент-серверный шаблон

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

Использование

· Онлайн приложения (электронная почта, совместный доступ к документам, банковские услуги).

3. Ведущий-ведомый

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

Использование

· В репликации баз данных. Там главная БД считается авторитетным источником, а подчиненные базы с ней синхронизируются.

· Периферийные устройства, подключенные к шине в компьютере (ведущие и ведомые устройства).

4. Каналы и фильтры

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

Использование

· Компиляторы. Последовательные фильтры выполняют лексический, синтаксический, семантический анализ и создание кода.

· Рабочие процессы в биоинформатике.

5. Шаблон посредника

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

Сервер размещает свои возможности (службы и характеристики) у посредника (брокера). Клиент запрашивает услугу у брокера. Затем брокер перенаправляет клиента к подходящей службе из своего реестра.

Использование

6. Одноранговый шаблон

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

Использование

· Проприетарные мультимедийные приложения (как тот же Spotify).

7. Шина событий

Этот шаблон, в основном, взаимодействует с событиями и состоит из 4 главных компонентов: источник события, прослушиватель события, канал и шина событий. Источники размещают сообщения для определенных каналов на шине событий. Прослушиватели подписываются на определенные каналы. Прослушиватели получают уведомления о появлении сообщений, размещенных на каналах из их подписки.

Использование

· Разработки на Android

8. Модель-представление-контроллер

Этот шаблон также известен как MVC-шаблон. Он разделяет интерактивные прикладные программы на 3 части:

1. модель — содержит ключевые данные и функционал;

2. представление — показывает информацию пользователю (можно задавать более одного представления);

3. контроллер — занимается обработкой данных от пользователя.

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

Использование

· Архитектура WWW-приложений, написанных на основных языках программирования.

9. Доска

Такой шаблон подходит для проблем, для которых отсутствуют четкие детерминированные решения. Шаблон «Доска» состоит из 3 главных компонентов:

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

· источник знания — специализированные модули со своим собственным представлением;

· компоненты управления — выбирает, настраивает и исполняет модули.

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

Использование

· идентификация и отслеживание транспортных средств;

· определение структур белка;

· интерпретация сигналов Sonar.

10. Интерпретатор

Он подходит для разработки компонента, который должен интерпретировать программы, написанные на специальном языке программирования. В основном, там расписано, как вычислять строки (иначе говоря: «предложения» или «выражения»), написанные на каком-то определенном языке программирования. Суть в том, чтобы присвоить класс каждому символу языка.

Использование

· языки запросов к базе данных (SQL);

· языки, которые используются для описания протоколов передачи данных.

Сравнение архитектурных шаблонов

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

Многоуровневый шаблон

• Одним низким слоем могут пользоваться разные слои более высокого ранга.
• Слои упрощают стандартизацию, т.к. мы четко определяем уровни.
• Изменения вносятся внутри какого-то одного слоя, при этом остальные слои остаются неизменными.

• Не универсален.
• В ряде ситуаций возможен пропуск некоторых слоев.

Клиент-серверный шаблон

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

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

Шаблон «Ведущий-ведомый»

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

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

Шаблон «Каналы и фильтры»

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

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

Шаблон «Посредник»

• Возможно динамическое изменение, добавление, удаление и перемещение объектов. Этот шаблон делает процесс распределения прозрачным для разработчика.

• Необходима стандартизация описаний служб.

Одноранговый шаблон

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

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

Шаблон «Шина событий»

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

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

Шаблон «Модель-представление-контроллер»

• Упрощает создание различных представлений одной и той же модели; их можно включить или отключить на этапе выполнения.

• Возрастает сложность алгоритма. Может привести ко многим ненужным корректировкам действий пользователей.

Шаблон «Доска»

• Легкое добавление новых приложений.
• Можно без труда расширять структуры пространства данных.

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

Шаблон «Интерпретатор»

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

• Проблемы с производительностью, т.к. интерпретированный язык медленнее скомпилированного.

Какую технологию выбрать или архитектура современных приложений

ru-RU | создано: 13.05.2015 | опубликовано: 13.05.2015 | обновлено: 02.01.2018 | просмотров за всё время: 10371

Так получилось, что у меня есть некоторый опыт по разработки приложений. Начала отсчета 2001 год, то есть когда C#.NET был у истоков. На сегодняшний день, в мой адрес звучат множество вопросов: Какие технологии актуальны? Какую архитектуру из каких технологий построить? Перспективы развития той или иной технологии? В общем, в этой статье поговорим про выбор технологии.

Направление

Ни для кого не секрет, что в мире IT существует множество технологий. Даже если говорить только о клиентской (front-end) части, то можно, навскидку, вспомнить такие как: AngularJS, KnockoutJS, EmberJS, BreezeJS, DurandalJS и другие. Если же говорить о серверной (back-end) части ПО, тут в последние время появилось тоже очень много возможностей, как то: Web API, OData, ASP.NET MVC, WCF-services. Хотя Microsoft и планирует объединить первые три в одно целое под названием MVC 6, технологии всё равно разные.

Так уж получилось, что я имею опыт работы c платформой .NET. А если конкретно, то ASP.NET на C# (хотя опыт есть и на Windows Mobile, Windows Phone, WPF, WCF и другие платформы). Когда-то я начинал с ASP.NET WebForms, позже перешел на ASP.NET MVC (о чем не жалею ни секунды). И в связи с этим, повествование будет идти касательно NET. А также мы поговорим о JavaScript.

История о JavaScript

В стародавние времена, когда .NET еще не было и в мыслях, была такая платформа ASP. Я обратил на нее внимание только начиная с версии 3.0. В те далекие времена, язык JavaScript (JS) был всего лишь дополнением к основному языку ASP 3.0 (серверная разметка в HTML). JS — выполнял вспомогательные функции для решения задач на клиентской стороне, потому что JavaScript выполняться в браузере на клиенте. Мелкие функции, простые расчеты и другие нетребовательные операции: отобразить сообщение об ошибке, проверить ввод пользователя, подставить значение по умолчанию и прочие функции – вот для чего в основном программисты использовали JS.

На данный момент, вот уже в течении 3-5 лет JS перерос в нечто большее, чем просто вспомогательный язык. Он приобрел статус самостоятельного основного языка для разработки по web. Язык может теперь работать напрямую с http-сервером (node.js), что ставит его на один уровень с другими языками.

Front-End

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

Итак, давайте рассмотрим часть “Клиент”, ведь именно это и есть Front-End. Желтая зона, состоящая из четырех подзон представляет собой простые понятия:

• базовые операции – определение namespace’ов, утилиты, настройки приложения, хелперы, вспомогательные функции и классы и другие обобщенные сборки полезных вещей. Это своего рода “кладовочка”, в которой полно разного инструмента и расходного материала на выбор. Здесь лежат базовые определения для приложения.
• Widgets – контролы и компоненты сторонних разработчиков, например, jQuery UI, Bootstrap и другие полезные компоненты (контролы) и UI-фреймворки.
• MV* frameworks – фреймворки на JavaScript, которые отвечают некоторым требованиям, то есть “знают” о маршрутизации (router), привязка данных (data-binding), шаблонные представления (template/views), модели (models) и доступ к данным (data access). MV* – представляет собой семейство паттернов MVC, MVP, MVVM. Примерами таких фреймворков могут послужить: backbone.js, knockoutjs, maria.js.
• JavaScript-библиотеки – сборки сторонних разработчиков, именно те, что являются вспомогательными инструментами или базовыми основами. Например, jQuery, underscore.js, moment.js и другие.

Всё, что объединено в нижнем блоке раздела “Клиент” можно назвать “App framework”. Реализации в конкретном приложении может значительно отличаться в зависимости от выбранных технологий и остальных сторонних фреймворков, которые перечислены в верхней (желтой) части раздела “Клиент”. Подробное описание этих компонентов системы мы отложим как темы для будущих статей, но сравнительную таблицу я всё-таки приведу:

Back-End

Пришло время рассмотреть часть “Сервер”, потому что вряд ли найдется сколько-нибудь полезный проект (сайт, приложение), который не был бы ни коим образом связан с данными (БД). Про сквозную интеграцию говорить особо нечего, единственное, что можно упомянуть, что, так или иначе, в любом проекте есть базовые операции, как то: чтение настроек, запись настроек, файловые операция чтения/записи и другие подобного рода обобщенные операции. Модули и сервисы которые управляют этими операциями носят имя – “управление операциями”.

Что касается “безопасности”, то тут существует огромное количество вариантов реализации: авторизация и аутентификация на основе ASP.NET SimpleMembership, Microsoft Identity, Open Auth и даже собственная реализация механизмов.

По остальным составляющим “кубика” “Web-сервер” пройдемся снизу вверх. Уровень доступа к данным (DAL) имеет в себе определение “Компоненты доступа к данным”. Под этим большим понятием кроются компоненты типа ORM (например, MS EntityFramework или LLBLGen). А также компоненты “прямого” доступа к БД (например, SQLDataReader, SqlCommand или кастомные реализации на их основе).

“Утилиты” подразумевают под собой вспомогательные средства для работы с БД. Например, генераторы схем БД или генераторы кода по типу таблицы, в общем разного рода помощники для роботы с БД и ее компонентами.

К “Сервисам” можно отнести такие компоненты как SQL Report Service или сервисы по синхронизации данных, сервисы распределяющие нагрузку или другого типа сервисы, которые работают непосредственно с БД.

“Уровень бизнес-логики” – это есть “приложение”, как раз то, чем определяются задачи и функции программы (web-приложения). Бизнес-логика приложения содержит привила управления данными проходящие через программу. Уровень бизнес-логики призван решать прикладные задачи.

“Уровень представления” – самый простой для понимания раздел архитектуры, потому что он лежит на “поверхности” и его можно “пощупать мышкой” 🙂 Представления генерирующие серверной частью приложения актуальны и на сегодняшний день, но позиции такого рода подхода стремительно падают в пользу HTML5. Мне доводилось встречать приложения достаточно мощные и многофункциональные, которые были сделаны практически без использования JavaScript, но эра таких web-приложений практически сошла на нет.

Концепция web-приложения

Современные web-приложения “стремятся” к виду Desktop-приложений, но специфика работы Web стандартов, то есть асинхронная модель поведения, когда на любой Request приходится ждать Response от сервера, накладывает ряд ограничений на дизайн и, соответственно, на архитектуру приложения. Примером может быть например, обязательное требование (в описании Web 2.0) уведомление пользователя о процессе запроса. То есть, если пользователь кликнул кнопку “отправить сообщение”, то программист должен уведомить пользователя о течении процесса, показав на время ожидания ответа от сервера о результате операции картинку анимации, или вывод динамического сообщения. Понятно, что подобного рода интерфейс может быть и в Desktop-приложениях, но для Web-платформы это ключевое понятие (особенно если учесть, что на Request не всегда приходит Response).

Вариант архитектуры для Web-приложения

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

Front-End:

• KnockoutJS – как фреймворк для связывания данных JavaScript-моделей с HTML. В ответ на очень частый вопрос “почему именно knockout” отвечаю. Принцип связывания данных у KnockoutJS построен на модели MVVM, что соответствует принципу в WPF и Silverlight, а значит мне не нужно переосмысливать базовые понятия, принципы и паттерны. Кстати сказать, AngularJS реализует принцип MVC, что не может не повлиять я внутренние концепции при реализации приложений с его использованием. OpenSource
• Для доступа к web-сервисам я использую jQuery.ajax(), иногда AmplifyJS, и совсем редко — вызовы напрямую через XMLHttpRequest. OpenSource
• Bootstrap – фреймворк для построения UI. Данный фреймворк создает адаптивную HTML-разметку, которая одинаково хорошо выглядит как на разных браузерах, так и на разных разрешениях экрана. OpenSource
• SiteJs – это набор скриптов для построения web-приложения по принципам SPA (и не только).

Back-End:

• Web API – современные решения для построения сервисов на основе RESTful. OpenSource
• EntityFramework – быстроразвивающийся ORM от компании Microsoft, который недавно стал OpenSource.
• ASP.NET MVC — как web-платформа для web-приложений. OpenSource. Альтернативой может быть node.js или Web API self-host. По сути, совершенно не важно какую web-платформу вы используете. Ключевой момент состоит в том, что HTML5 может работать на любой, а сервис предоставляющий данные для вашего приложения, может быть как платформе ASP.NET, так и на других современных платформах, вплоть до сторонних сервисов.

Заключение

На этом наверное, всё. Единственное, что стоит отметить, так это то, что каждый из вас вправе выбирать любую удобную и близкую по духу конфигурацию архитектуры приложения. В этой статье я озвучил лишь базовые понятия и основные принципы построения современного web-приложения (сайта). С другой стороны, у каждого из выбранного компонента архитектуры есть свои плюсы и минусы. Умея ловко подбирать “правильные кубики” позволит в дальнейшем: а) избежать необходимость “переделки” приложения или его частей; б) с легкостью поддерживать приложение, обновляя сборки и фреймворки на новые более производительные версии; в) идти в ногу со временем, применяя новые стандарты в программировании и дизайне.