Архитектура ПО Разработка бизнес приложений Лекция 9
Архитектура ПО
Разработка бизнес приложений Лекция 9
Что такое архитектура
• Четкого определения нет• Все что отвечает на вопрос «а как именно
это сделать»?– Классы– Компоненты (модули, сервисы, слои)– Процессы и приложения– Физические сервера
• Совокупность тяжело изменяемых решений принимаемых в процессе проектирования
Зачем нужно думать о ней заранее?
• Некоторые вещи очень сложно сделать в процессе
• Нужно постоянно бороться со сложностью (энтропией)
• В принципе, идеальная команда все знающих программистов может «просто писать код» и, скорее всего, все у них будет хорошо
Две архитектуры
• Логическая– Как организован код внутри – слои, модули– Выбор готовых компонентов и инструментов
• Физическая– Набор, ответственность и взаимосвязь
процессов ОС– Вопросы размещения процессов на физ.
серверах, масштабирования
ЛОГИЧЕСКАЯ АРХИТЕКТУРА
Слои (layers)
• Способ представления программы в виде слабо зависимых кусков– Прежде всего, логических кусков– Но, бывает, что слои и физически разделены
• Каждый слой оперирует собственным набором терминов и понятий– Следовательно, проще в понимании чем
система целиком
Преимущества слоев
• Упрощение изучения системы• Можно выбрать альтернативную реализацию
того или иного слоя– (в теории)
• Каждый слой является удачным кандидатом на стандартизацию / автоматизацию
• Созданный слой может служить основой для нескольких различных слоёв более высокого уровня.
Недостатки слоев
• Каскадные изменения практически неизбежны
• Очень трудно четко определить, донести до всех и проконтролировать (!) границы ответственности слоя– Если слои физически не разделены
Три основных слоя
• DAL (Data access layer)– Как сохранять и получать данные (persistent)– Постепенно отмирает, заменяется ORM+БД
• BL(L) (Business logic layer)• Как делать работу, выполнять бизнес операции
• UI (User Interface layer, представление)– От HTML до консоли или API– Как выводить результаты
Вариант DAL: прямые запросы
• Открываем соединение• Отправляем запрос• Получаем строки БД• Закрываем соединение• Доступно на любом языке, масса
стандартных библиотек– JDBC, ADO.NET, ODBC…
Достоинства
• Полный контроль над кодом доступа к БД• Возможность использовать нестандартный SQL,
сложным образом оптимизировать запросы• Подход не требует никаких нестандартных
библиотек, прост в установке и настройке• Простота освоения. Нужно просто знать SQL• Относительно высокая скорость работы
конечного приложения. Но только при хорошем SQL коде.
Недостатки
• Огромное дублирование кода, весь код - однотипный• Высокая вероятность ошибок, т.к. SQL не проверяется
автоматически• Низкая скорость разработки, так как приходиться
аккуратно писать большое количество однотипного, не проверяемого кода
• Нужно хорошее знание SQL• Сложность внесения изменений, из-за большого
количества дублируемого интерпретируемого кода• Зависимость от конкретного диалекта СУБД
В результате – DAL и ORM
• DAL как попытка исключить дублирование кода
• Естественное желание автоматически загружать строки из БД в виде объектов, а не слабо типизированных таблиц.
• ORM (Object-relational mapping)– Библиотека осуществляющее автоматическое
преобразование (mapping) реляционных данных в объекты и обратно
Сложности реализации ORM
• Гранулярность (Granularity)• Подтипы (Subtypes)• Идентификация (Identity)• Навигация по связям (Graph Navigation)
Гранулярность
• Удобные (оптимальные) формы хранения объектных и реляционных данных далеко не всегда совпадают
Наследование
1. TPT (нужны запросы к базовому классу)2. TPCT (к отдельным классам)3. TPH (ко всем разом)
1
2
3
Идентификация
• В БД строка всегда одна– Характеризуется PK
• В памяти приложения можно создать несколько объектов отображающих одну и ту же строку– Характеризуются адресами в памяти
• ORM должен предлагать консистентные правила идентификации отображенных объектов
Моделирование связей
• С т.ч. объектной модели мы имеем дело с простым графом объектов – переходы по ссылкам между объектами – тривиальны
• С т.ч. БД мы имеем дорогостоящие запросы по FK, сложные JOIN и, потенциально, бесконечное количество данных
• ORM должен предлагать подходы к решению этой проблемы – Lazy loading (+/-)– Eager loading (решение n+1)
Слой бизнес логики (модель)
• Объекты предметной области• В контроллерах (UI)• Набор отдельных методов (Transaction
Script)• Промежуточный вариант UnitOfWork
(бизнес транзакция) + ORM + команды
Слой UI. MVC
• Вариации -> MVVM(C), MVP• Зависит от UI фреймворка, но хороший фреймворк
всегда отделяет view от управления UI и бизнес логики– Тестируемость– Императивный код во View (asp/php макароны)
Модули
• Попытка разделить физическое приложение вертикально, обособив некие относительно независимые части, каждую со своим стеком слоев UI / BL / DAL.
• Сложно в реализации и поддержке, мало плюсов, т.к. разделение сугубо логическое.
• Имеет смысл в виде динамических плагинов
Шаблон Inversion of Control (Dependency Injection)
• Состав– Контейнер: «интерфейс» – «реализация»– Инжектор (автоматический или не очень)
• Преимущества– Снижение каплинга, повышение гибкости, возможность реализации
AoP (иногда)• Недостатки
– Код становится менее прозрачным при чтении– Доп. сложность и конфигурация – Поощрение мешанины зависимостей
• Фактически, это замена качественного проектирования слоев / модулей и логической архитектуры как таковой– Редко когда действительно нужно
Общие рекомендации. Не усложняйте.
• ORM + MVC на основе готовых фреймворков
• Без выделенного слоя бизнес логики• Без DI / IoC • Без явного выделения слоев• Без явного деления на модули– если не нужны плагины (тогда нужно делать их)
ФИЗИЧЕСКАЯ АРХИТЕКТУРА
Распределенные системы
• Распределённая система состоит из различных процессов ОС, чаще всего распределенных по серверам различной степени удаленности и связности– Клиент-сервер БД – Веб приложение с логикой на клиенте– Географически распределенные системы
Преимущества физического разделения
• Общий прозрачный доступ к географически распределенным ресурсам
• Открытость – предоставление доступа к частям системы через программные интерфейсы (интеграция)
• Масштабируемость• Упрощение большой системы (разделение
на куски)• Отказоустойчивость
Недостатки физического разделения
• Возможно сокращение отказоустойчивости – если нет горячего дублирования
• Снижение производительности за счет сериализации / десериализации (маршаллинга) и задержек передачи данных – Если неправильно распараллеливается нагрузка
• Дополнительная сложность – требования сериализации объектов– DTO, фасады, доп. слои– Отсутствие состояния или параллельный доступ к нему– Сложная конфигурация развертывания
Способы связи
• TCP/IP (сокеты)– Быстро и сложно, не масштабируется
• Системы распределённых объектов– Не очень хорошо работают, слишком прозрачны,
закрытые и требующие изучения реализации• Вызов удалённых процедур
– Стандартно, прозрачно и несложно, но не быстро и дает сложную связь по интерфейсам
• Системы передачи сообщений.– Строго асинхронно, весьма сложно, нужны отдельные
приложения со своей инфраструктурой и сложностями
Клиент-сервер (2-tier?)
• Веб приложение – подходит или нет?• Чаще всего под этим понимают классический
толстый клиент к БД (1С)• Не масштабируется по географии и кол-ву
пользователей• Сложности в развертывании администрировании
и защите (БД открыта)
N-Tier (многозвенная)
• Веб приложение – подходит или нет?• Хуже скорость реакции (?)• Беднее интерфейс (?)• Одностороннее взаимодействие (?)
Peer to peer (p2p)
• Специфические области применения– Torrents– Skype– Научные вычисления
• Проблемы обнаружения (discovery)• Сложность разработки и отладки
Состояние сеанса (сессия)
• На стороне клиента–Cookies–Hidden fields– Толстый клиент (rich client)
• На стороне сервера–В памяти сервера–В распределенном кэше–В базе данных
SOA
• Сервис = все слои, законченый функционал• Распределяем не слои, а сервисы• Психология – неявные сервисы в коде vs
явные веб сервисы• Нарезаем вертикально, а не горизонтально• Например: протоколы OSI (часто приводят
как слои, но я считаю что это сервисы)– Ethernet - TCP/IP - HTTP
Что такое интеграция
• Частный случай распределённости, когда одна из частей системы написана и/или контролируется не вами
• Часто возникает не от «хорошей» (с т.ч. IT) жизни (но бывает и намеренным решением)– Слияние предприятий– Бурное развитие с последующей консолидацией IT– Системы допоставок– Невозможность написать одну систему на все
предприятие
Проблемы интеграции• Минимизация связности
– Нельзя усложнять развитие каждой системы, т.к. релиз циклы и скорость развития обычно существенно различны
• Сложность интеграции– Чаще всего требуется сделать очень быстро, без существенных
изменений в одной из систем или без изменений вовсе.• Договоренность о формате данных • Синхронная или асинхронная (допустимое время
запаздывания данных, интеграция данных или функциональности)– Конфликты данных при асинхронном обмене – Обработка ошибок когда одно из приложений недоступно– Проблемы распределенных транзакций при синхронном обмене
Способы интеграции
• Обмен файлами• Разделяемая БД• Remote Procedure Call (XML-RPC, Web services,
REST), т.е. вызов удаленных функций– Реальный RPC (как функции, синхронный)– Импорт / Экспорт (как замена обмена файлами,
асинхронно)• Передача сообщений (messaging) – Общая система обмена сообщениями, которая позволяет
обмениваться данными и командами в виде сообщений.
Распределенные транзакции
• Распределенные транзакции– Очень сложно– Медленно
• По возможности – заменяем идемпотентной операциями– Вторая и последующая операция ничего не
меняют по отношению к 1й– Легко реализуется через уникальные ID / Guid
Рекомендации по интеграции
• RESTful web сервисы на основе XML (и/или JSON)– WS* (SOAP) – отказать
• Односторонняя интеграция без конфликтов данных– Простые очереди или периодические запросы
• Никаких распределенных транзакций– Идемпотентность – transactionid + очереди в БД
• При синхронной интеграции воспринимайте систему как единое целое– Т.е. просто падаем, если что-то не работает
Рекомендации по распределённости
• Выберите веб приложение: веб сервер(а) + БД, потом успеете распределить– Минимум состояния сеанса (лучше без)
• Распределяйте вертикально, не горизонтально– SOA
• Избегайте географического распределения и любой двухсторонней синхронизации данных
• Идеал – прототипы и нагрузочное тестирование, очень трудно угадать влияние распределённости на производительность
Совсем общие рекомендации
• Смысл архитектуры – борьба со сложностью, а не ее внесение– BDUF - антипаттерн– Заранее нужно принимать только решения направленные
на борьбу с «очевидными» рисками– Проектировать только то, что потом будет сложно (дорого)
изменить• Используйте готовое
– NiH синдром– Всегда приходится чем-то жертвовать (где граница?)
• В остальном - решать конкретные проблемы
Читаем
• Шаблоны корпоративных приложений• Предметно-ориентированное проектирова
ние (DDD)
• Применение DDD и шаблонов проектирования. Проблемно-ориентированное проектирование приложений с примерами на C# и .NET
Использованные материалы
• Никита Филлипов (www.scrumtrek.ru), Сергей Дмитриев (www.agilecoach.ru). Курс SCPO Msk (31.08.11)
• Бочков Илья (Архитектура корпоративных приложений, МИФИ)
• MIT: открытые лекции по CS– http://ocw.mit.edu/courses/#
electrical-engineering-and-computer-science• http://www.refactoring.com (Мартин Фаулер)
Объявления
• 8го экзамен
Темы для докладов
• AOP• Kanban / Lean • SCRUM: Team / ScrumMaster – подробнее
про процесс (DS, Retro, SprintPlan, Demo…)• NoSql БД• Реализация ООП в Javascript (прототипы)
Лабы
• Обработка открытых данных– http://minenergo.gov.ru/activity/statistic/,http
://www.fms.gov.ru/about/ofstat/, http://www.federalspace.ru/main.php?id=10, http://ivan.begtin.name/2011/10/02/gosuslugijson/
• Индивидуальное задание (для тех, у кого уже есть что показать)
• Нужно:– Или наличие БД– Или наличие веб интерфейса