Комментарии 6
Статья понравилась. Вопрос: что даёт такой подход руководителю проекта кроме оценки сроков/потребных ресурсов и расчёта трудоёмкости (для оплаты коллективу)?
Статья описывает лишь небольшую часть подхода к проектированию клиентских приложений. Если использовать этот подход, то некоторые риски, связанные с тем, что непонятно, какая должна быть архитектура, какого дизайна следует придерживаться и т.д., просто уходят. Процесс разработки преобразуется в последовательность этапов (не только в управленческом смысле, но и в техническом), которые имеют свои конкретные результаты и которые просто нужно выполнить.
Методики проектирования каждого слоя (или в терминах данной статьи — уровня) различаются. Например, на каждом уровне используются свои подходы к выявлению классов.
Методики проектирования каждого слоя (или в терминах данной статьи — уровня) различаются. Например, на каждом уровне используются свои подходы к выявлению классов.
НЛО прилетело и опубликовало эту надпись здесь
Спасибо!
Уровень редактирования поддерживает 2 важные вещи:
1. Архитектуру Документ-Вид (когда с каждым документом связывается один или несколько видов). В простейшем случае, для документа «визуальный эффект» создается окно редактирования этого визуального эффекта.
2. Undo/Redo стек, который поддерживает возможность отмены операции.
Эти две вещи довольно-таки общие для разных редакторов. По этой причине я и предлагаю вынести их в отдельный слой (уровень).
Уровень редактирования поддерживает 2 важные вещи:
1. Архитектуру Документ-Вид (когда с каждым документом связывается один или несколько видов). В простейшем случае, для документа «визуальный эффект» создается окно редактирования этого визуального эффекта.
2. Undo/Redo стек, который поддерживает возможность отмены операции.
Эти две вещи довольно-таки общие для разных редакторов. По этой причине я и предлагаю вынести их в отдельный слой (уровень).
Спасибо больше за подробно расписанные кейсы, этого как воздух не хватает. Все почему-то учатся проектировать на примерах уровня Hello World, а потом удивляется, что получается «лапша».
Я в итоге пришел к точно такой же схеме разбиения GUI приложений. Я рассуждал как-то так:
1. Пользователь, как правило, хочет запустить какую-нибудь «сложную функцию», с большим числом параметров.
2. Но при этом у него есть клавиатура и мышь/пальцы, то есть «за раз» много информации он ввести не может.
3. Значит надо иметь слой в котором кусочки информации будут накапливаться и агрегироваться. Это слой Редактирования у вас и слой View Model у меня.
4. Когда информации достаточно, надо запустить «сложную функцию». Из соображений повторного использования эту «сложную функцию» стоит определить в какой-нибудь сервис.
В итоге путь данных от пользователя в систему и назад выглядит аналогично вашей пятиуровневой модели
1. Вид
2. View Model, слой редактирования и накопления данных от пользователя
3. Сервисы — ради выполнения функции какого-то сервиса пользователь и использует приложение.
4. Модель данных — структуры данных, которые легко сохранить/загрузить и с которые работает сервис. Чаще всего они еще торчат наружу из сервисов.
Инфраструктура — она как-бы сбоку получается, потому что WPF это инфраструктура, но для вида, а LINQ это тоже инфраструктура, но уже скорее для сервисов/модели.
Я объясняю наличие этих 5 слоев тем, что пользователь использует конкретные устройства ввода, а слои это уже следствие. А вот API приложения уже другие, там «ввод» это JSON/XML поэтому слоя редактирования уже не нужно.
Вопрос который меня мучает последнее время — как найти оптимальное разбиение системы на слои в заданной ситуации. Или аналогично — как показать, что разбиение на эти 5 слоев является в некотором смысле оптимальным?
Я в итоге пришел к точно такой же схеме разбиения GUI приложений. Я рассуждал как-то так:
1. Пользователь, как правило, хочет запустить какую-нибудь «сложную функцию», с большим числом параметров.
2. Но при этом у него есть клавиатура и мышь/пальцы, то есть «за раз» много информации он ввести не может.
3. Значит надо иметь слой в котором кусочки информации будут накапливаться и агрегироваться. Это слой Редактирования у вас и слой View Model у меня.
4. Когда информации достаточно, надо запустить «сложную функцию». Из соображений повторного использования эту «сложную функцию» стоит определить в какой-нибудь сервис.
В итоге путь данных от пользователя в систему и назад выглядит аналогично вашей пятиуровневой модели
1. Вид
2. View Model, слой редактирования и накопления данных от пользователя
3. Сервисы — ради выполнения функции какого-то сервиса пользователь и использует приложение.
4. Модель данных — структуры данных, которые легко сохранить/загрузить и с которые работает сервис. Чаще всего они еще торчат наружу из сервисов.
Инфраструктура — она как-бы сбоку получается, потому что WPF это инфраструктура, но для вида, а LINQ это тоже инфраструктура, но уже скорее для сервисов/модели.
Я объясняю наличие этих 5 слоев тем, что пользователь использует конкретные устройства ввода, а слои это уже следствие. А вот API приложения уже другие, там «ввод» это JSON/XML поэтому слоя редактирования уже не нужно.
Вопрос который меня мучает последнее время — как найти оптимальное разбиение системы на слои в заданной ситуации. Или аналогично — как показать, что разбиение на эти 5 слоев является в некотором смысле оптимальным?
Мне кажется, что при проектировании не нужно сразу искать оптимальную декомпозицию системы на слои. Нужно сделать хоть какое-то разбиение. Это будет первым шагом к разработке структуры. Затем, анализируя дополнительные функции системы, Вам неприменно потребуется решить, к какому слою абстракции их отнести. Нужно понять, какая подсистема будет отвечать за реализацию каждой конкретной функции и где она будет находиться. Возможными ответами на эти вопросы будут: разбиение функций на подфункции, делегирование их разным подсистемам, размещение этих подсистем на разных системных уровнях и, возможно, создание дополнительных системных уровней.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Архитектура клиентского приложения (механизмы структуризации)