Comments 6
Статья понравилась. Вопрос: что даёт такой подход руководителю проекта кроме оценки сроков/потребных ресурсов и расчёта трудоёмкости (для оплаты коллективу)?
Статья описывает лишь небольшую часть подхода к проектированию клиентских приложений. Если использовать этот подход, то некоторые риски, связанные с тем, что непонятно, какая должна быть архитектура, какого дизайна следует придерживаться и т.д., просто уходят. Процесс разработки преобразуется в последовательность этапов (не только в управленческом смысле, но и в техническом), которые имеют свои конкретные результаты и которые просто нужно выполнить.
Методики проектирования каждого слоя (или в терминах данной статьи — уровня) различаются. Например, на каждом уровне используются свои подходы к выявлению классов.
Методики проектирования каждого слоя (или в терминах данной статьи — уровня) различаются. Например, на каждом уровне используются свои подходы к выявлению классов.
UFO just landed and posted this here
Спасибо!
Уровень редактирования поддерживает 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 слоев является в некотором смысле оптимальным?
Мне кажется, что при проектировании не нужно сразу искать оптимальную декомпозицию системы на слои. Нужно сделать хоть какое-то разбиение. Это будет первым шагом к разработке структуры. Затем, анализируя дополнительные функции системы, Вам неприменно потребуется решить, к какому слою абстракции их отнести. Нужно понять, какая подсистема будет отвечать за реализацию каждой конкретной функции и где она будет находиться. Возможными ответами на эти вопросы будут: разбиение функций на подфункции, делегирование их разным подсистемам, размещение этих подсистем на разных системных уровнях и, возможно, создание дополнительных системных уровней.
Sign up to leave a comment.
Архитектура клиентского приложения (механизмы структуризации)