У меня возник вот такой вопрос.
Есть объект, он может быть представлен по разному в зависимости от стадии разработки
или использования этого объекта.
Скажем так есть три вида вид1, вид2, вид3 и этот объект во всех этих видах представляется
по разному и набор даных в принципе тоже расширяется от одного вида к другому.
Тоесть вид1 — самое простое (схематическое) представления объекта,
вид3 — самый сложный (детальный), можно сказать специфическое представление объекта.
Так вот можно ли здесь использовать MVC? Меня немного смущает то что здесь как бы разные
наборы даних, хотя из сложной структуры всегда можно извлечь часть необходимых даних для
любого вида, но это уже как бы накладные расходы получается...
Ну или такой вариант сделать иерархию класов от простого до сложного и уже в модели создавать
нужний клас в зависимости от того в каком представлении будет отображатся обект, хотя мне
кажется это уже ломает всю идею MVC.
Ну и какая организация модели должны быть? Ведь здесь обекты не представлены ни таблицой
ни списком, просто структура даных.
Так вот, что посоветуете? А то я только взялся за это дело и хотелось бы грамотно все сделать,
хотя я себя не считаю крутым програмером...
Здравствуйте, skydion, Вы писали:
S>Так вот, что посоветуете? А то я только взялся за это дело и хотелось бы грамотно все сделать, S>хотя я себя не считаю крутым програмером...
На мой взгляд, следует отказаться от единого представления объекта для всех трёх видов. Лучше поступить так:
Представить, что у Вас имеются 4 подсистемы: модель (отвечает за основные бизнес-операции), вид1 (визуализирует объект в виде1), вид2 (визуализирует объект в виде2), вид3 (визуализирует объект в виде3).
Для каждой подсистемы создать свою модель представления объекта, которая никак не связана с моделями из других подсистем. Иными словами, класс объекта для подсистемы "модель" включает ровно те данные и операции, которые нужны для подсистемы "модель". Класс объекта для подсистемы "вид1" содержит только те данные, которые нужны для рисования объекта в виде1. И т.д.
Продумать механизмы связи между подсистемами. Т.е. изменение объекта в подсистеме "модель" должно привести к изменению объекта в подсистемах "вид1", "вид2" и "вид3".
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Представить, что у Вас имеются 4 подсистемы: модель (отвечает за основные бизнес-операции), вид1 (визуализирует объект в виде1), вид2 (визуализирует объект в виде2), вид3 (визуализирует объект в виде3).
Да, подходит, но это не конечное число, возможно здесь лутше применить архитектуру плугинов?
Потому что на перед как бы неизвестно число этих видов и возможных вариантов манипулирования и использования объектов.
По идее все эти модели и виды должны работать со своми даными, но даные должны как бы перетекать из одного вида в другой, как бы наращивая мощь объекта. К приему если объект редактируется в виде №1 он не должен терять своих свойств которые ему назачились в виде №3. В общем это уже смахивает на распределенную архитектуру...
КЛ>Для каждой подсистемы создать свою модель представления объекта, которая никак не связана с моделями из других подсистем. Иными словами, класс объекта для подсистемы "модель" включает ровно те данные и операции, которые нужны для подсистемы "модель". Класс объекта для подсистемы "вид1" содержит только те данные, которые нужны для рисования объекта в виде1. И т.д.
Я так понимаю надо всетаки делать иерархию класов, чем глубже тем более наворочеными стают класы? И уже для каждого из этих класов делать свою модель, контролер и нужные виды? А где содавать сами контейнеры даных?
КЛ>Продумать механизмы связи между подсистемами. Т.е. изменение объекта в подсистеме "модель" должно привести к изменению объекта в подсистемах "вид1", "вид2" и "вид3".
Да это тоже очень важно, я немного затронул эту тему в первом пункте, а кокие есть возможности создания такой связи?
Здравствуйте, skydion, Вы писали:
S>Да, подходит, но это не конечное число, возможно здесь лутше применить архитектуру плугинов? S>Потому что на перед как бы неизвестно число этих видов и возможных вариантов манипулирования и использования объектов.
Я так понимаю, что каждый вид будет "заточен" под определённую операцию или группу операций, которые можно выполнить над объектом? В таком случае, Вам сначала всё-таки нужно выяснить, сколько будет операций, что они будут делать и в каком порядке будут выполняться. Если Вы этого не сделаете сейчас, то Вас ждёт потом длинный и неприятный "секс" с системой, и никакие плагины тут не помогут.
S>По идее все эти модели и виды должны работать со своми даными, но даные должны как бы перетекать из одного вида в другой, как бы наращивая мощь объекта. К приему если объект редактируется в виде №1 он не должен терять своих свойств которые ему назачились в виде №3. В общем это уже смахивает на распределенную архитектуру...
Поэтому вид должен обращаться к модели за тем, чтобы изменить объект. Вид хранит только те данные, которые нужны для визуализации.
S>Я так понимаю надо всетаки делать иерархию класов, чем глубже тем более наворочеными стают класы? И уже для каждого из этих класов делать свою модель, контролер и нужные виды? А где содавать сами контейнеры даных?
Нет. В каждой подсистеме у Вас должны быть свои типы данных. Если там и потребуются иерархии, то они будут весьма простыми и небольшими.
S>Да это тоже очень важно, я немного затронул эту тему в первом пункте, а кокие есть возможности создания такой связи?
Просто продумайте хороший интерфейс взаимодействия между моделью и видами. Например, это можно сделать так (показываю очень схематично):
Чтобы пользователь мог выполнить определённую операцию, вид1 должен представлять объект так-то и так-то.
Чтобы можно было нарисовать такое представление, нужно получить у модели такие-то и такие-то данные в таком-то и таком-то порядке.
Чтобы можно было получить у модели такие данные, модель должна поддерживатиь такие-то и такие-то операции.
И т.д.
Хорошо, давайте тогда рассмотрим этот вопрос на примере. К примеру используем такое понятие как стена дома.
Думаю все знаю что стены бывают сделаны из разных материалов, притом в зависимости от этого используются разные
конструкции для постройки этих стен. Так вот есть такое понятие как стадия разработки проекта.
Этих стадий может быть несколько вот простой пример:
1. Предподготовка
2. Клаузура
3. Архитектурное планирование
4. Конструкционное проектирование
Вся соль в том что можно начать проектирование со стадии №2 или же со стадии №3, можно идти по порядку 1-4,
конечно самые крутые могут и с №4, но все эти стадии может делать один человек и может делать несколько причем
на некотором уровне уже практически одновременно (при некоторых условиях). Это детали которые возможно помогут
лучше разобратся со всем этим.
Так вот на стадии №2 объект стена может выглядеть как линия (прямая, кривая) это сути не меняет, уже на стадии №3
эта стена приобретает новые свойства, как толщина, внешняя, внутрення и так далее, а уже на стадии №4 она может
содержать много новых объектов которые создаются в зависимости от конструкции стены.
Притом конструктор имеет полное право сделать изменения сам в некоторых моментах, к примеру передвинуть несущую
стену если к примеру пролет слишком большой, или сказать архитектору чтобы он это сделал.
Так вот, я так думаю модели, это и есть эти стадии проектирования, виды это есть то как эти модели отображаюся
в своем модуле. Притом как я уже говорил, этих модулей может быть больше смотря насколько разрастется это
приложение и какие задачи будут еще решать с его помощью.
Тепер вернемся к стадиям
Стадия №2 (клаузура). На этой стадии можно и желательно манипулировать простыми объектами, такими как линия,
прямоугольник, ну чисто геометрические фигуры со своими методами редактирования и представления, скажем так
это концептуальный уровень.
Стадия №3 (архитектура). На этой стадии все объекты стади №2 дополняюся новыми свойствами, новыми методами
редактирования и измененным методом рисования, здесь уже иде доработка той концептуальной модели что была сооружена
на стадии №2. Плюс ко всему вводятся новые объекты которые не нужны на стадии №2.
Кстати здесь может быть уже два Вида 2D и 3D.
Стадия №4 (конструкции) здесь же опять все расширяется, и детализируется.
Ну и еще одно... объекты должны быть не только графически редактируемы но чтобы их можно было создавать с
помощю визардов, скажем на стадии №2, а дальше уже идет доработка во всех других стадиях.
Так вот, как Вы думаете может здесь еще фабрику этих вот объектов сделать? Смотрю я так что приложение буде
очень даже непростое... но поле дла фантазии еще то...
ПС. Может кто-то еще при наличии свободного времени и интереса посодействует в этом мозговом штурме?
Заранее благодарен.
Здравствуйте, skydion, Вы писали:
S>Так вот, как Вы думаете может здесь еще фабрику этих вот объектов сделать? Смотрю я так что приложение буде S>очень даже непростое... но поле дла фантазии еще то...
Понятно. Предлагаю Вам пока не заморачиваться с графическими редакторами и визардами, а хорошенько проработать модель. Понятно, что на разных стадиях она будет состоять из разных элементов. Поэтому рекомендую Вам поступить так:
Составить полный перечень стадий процесса проектирования.
Для каждой из стадий указать её обязанности (т.е. ответить на вопрос: Какие действия будут выполняться над моделью на этой стади?)
Исходя из обязанностей, для каждой стадии указать элементы, из которых будет состоять объект проектирования.
После того, как п.п. 1 — 3 будут выполнены, можно будет подумать и о том, как визуализировать стадии и подобрать подходящие для них виды (окна редактирования с графическими примитивами, визарды и т.п.).
S>Хорошо, давайте тогда рассмотрим этот вопрос на примере. К примеру используем такое понятие как стена дома. S>Думаю все знаю что стены бывают сделаны из разных материалов, притом в зависимости от этого используются разные S>конструкции для постройки этих стен. Так вот есть такое понятие как стадия разработки проекта.
S>Этих стадий может быть несколько вот простой пример: S>1. Предподготовка S>2. Клаузура S>3. Архитектурное планирование S>4. Конструкционное проектирование
S>Вся соль в том что можно начать проектирование со стадии №2 или же со стадии №3, можно идти по порядку 1-4, S>конечно самые крутые могут и с №4, но все эти стадии может делать один человек и может делать несколько причем S>на некотором уровне уже практически одновременно (при некоторых условиях). Это детали которые возможно помогут S>лучше разобратся со всем этим.
S>Так вот на стадии №2 объект стена может выглядеть как линия (прямая, кривая) это сути не меняет, уже на стадии №3 S>эта стена приобретает новые свойства, как толщина, внешняя, внутрення и так далее, а уже на стадии №4 она может S>содержать много новых объектов которые создаются в зависимости от конструкции стены.
S>Притом конструктор имеет полное право сделать изменения сам в некоторых моментах, к примеру передвинуть несущую S>стену если к примеру пролет слишком большой, или сказать архитектору чтобы он это сделал.
S>Так вот, я так думаю модели, это и есть эти стадии проектирования, виды это есть то как эти модели отображаюся S>в своем модуле. Притом как я уже говорил, этих модулей может быть больше смотря насколько разрастется это S>приложение и какие задачи будут еще решать с его помощью.
S>Тепер вернемся к стадиям S>Стадия №2 (клаузура). На этой стадии можно и желательно манипулировать простыми объектами, такими как линия, S>прямоугольник, ну чисто геометрические фигуры со своими методами редактирования и представления, скажем так S>это концептуальный уровень.
S>Стадия №3 (архитектура). На этой стадии все объекты стади №2 дополняюся новыми свойствами, новыми методами S>редактирования и измененным методом рисования, здесь уже иде доработка той концептуальной модели что была сооружена S>на стадии №2. Плюс ко всему вводятся новые объекты которые не нужны на стадии №2. S>Кстати здесь может быть уже два Вида 2D и 3D.
S>Стадия №4 (конструкции) здесь же опять все расширяется, и детализируется.
S>Ну и еще одно... объекты должны быть не только графически редактируемы но чтобы их можно было создавать с S>помощю визардов, скажем на стадии №2, а дальше уже идет доработка во всех других стадиях.
S>Так вот, как Вы думаете может здесь еще фабрику этих вот объектов сделать? Смотрю я так что приложение буде S>очень даже непростое... но поле дла фантазии еще то...
Прошу прощения за оверквотинг, но не хочется потерять масштабность предыдущего сообщения.
Меньше витайте в облаках. Если теоретизируете, подтверждайте доводы прототипами.
КЛ>>Представить, что у Вас имеются 4 подсистемы: модель (отвечает за основные бизнес-операции), вид1 (визуализирует объект в виде1), вид2 (визуализирует объект в виде2), вид3 (визуализирует объект в виде3).
Про контроллер забыли
S>Да, подходит, но это не конечное число, возможно здесь лутше применить архитектуру плугинов?
Зачем? Вроде обычная MVC. S>Потому что на перед как бы неизвестно число этих видов --> V S>и возможных вариантов манипулирования и использования --> C S>объектов. --> M S>По идее все эти модели и виды должны работать со своми даными, но даные должны как бы перетекать из одного вида в другой, как бы наращивая мощь объекта. К приему если объект редактируется в виде №1 он не должен терять своих свойств которые ему назачились в виде №3.
Именно так. S>В общем это уже смахивает на распределенную архитектуру...
А что мешает MVC быть распределённой?
БОльшая часть архитектуры будет зависеть от того как вы собираетесь хранить состояния.
Здравствуйте, VGn, Вы писали:
КЛ>>>Представить, что у Вас имеются 4 подсистемы: модель (отвечает за основные бизнес-операции), вид1 (визуализирует объект в виде1), вид2 (визуализирует объект в виде2), вид3 (визуализирует объект в виде3). VGn>Про контроллер забыли
S>>Да, подходит, но это не конечное число, возможно здесь лутше применить архитектуру плугинов? VGn>Зачем? Вроде обычная MVC. S>>Потому что на перед как бы неизвестно число этих видов -->> V S>>и возможных вариантов манипулирования и использования -->> C S>>объектов. -->> M S>>По идее все эти модели и виды должны работать со своми даными, но даные должны как бы перетекать из одного вида в другой, как бы наращивая мощь объекта. К приему если объект редактируется в виде №1 он не должен терять своих свойств которые ему назачились в виде №3. VGn>Именно так. S>>В общем это уже смахивает на распределенную архитектуру... VGn>А что мешает MVC быть распределённой? VGn>БОльшая часть архитектуры будет зависеть от того как вы собираетесь хранить состояния.
Да понимаете, я уже сам заплутался во всем этом
Для меня одного это слишком большой проект... но это как бы говоря идея фикс.
И я никогда не имел дела с такими большими проектами...
Сейчас, вот сижу делаю первую стадию... думаю здесь уже вырисуется некоторая
систематизация, которую уже перенесу на другие стадии... а дальше буду или
переделывать или расширять...
S>Сейчас, вот сижу делаю первую стадию... думаю здесь уже вырисуется некоторая S>систематизация, которую уже перенесу на другие стадии... а дальше буду или S>переделывать или расширять...
Тогда в общем-то не стоит париться. Здесь подойдёт обычное эволюционное прототипирование. Или существует жёсткая необходимость фиксации реализации?
Здравствуйте, VGn, Вы писали:
VGn>Тогда в общем-то не стоит париться. Здесь подойдёт обычное эволюционное прототипирование. Или существует жёсткая необходимость фиксации реализации?
Да нет не существует, видимо будем эволюционировать понемногу...
Просто хотел сразу заложить фундамент, но видимо еще не созрел
А эта тема возникла после того как я понял что эту идею хорошо бы на MVC прикрутить.
S>А эта тема возникла после того как я понял что эту идею хорошо бы на MVC прикрутить.
Вообще-то процесс разработки и архитектура — немного разные категории. С этим вопросом лучше в форум management обращаться. И тем более архитектурные паттерны врядли подойдут для решения вопросов процессов разработки продукта (разве что развития).
Здравствуйте, VGn, Вы писали:
VGn>Вообще-то процесс разработки и архитектура — немного разные категории. С этим вопросом лучше в форум management обращаться. И тем более архитектурные паттерны врядли подойдут для решения вопросов процессов разработки продукта (разве что развития).
Ну хорошо, я даже спорить не буду, что я в этом деле чайник.
А вот Вы как бы подошли к решению такой задачи? С чего бы начали?
S>А вот Вы как бы подошли к решению такой задачи? С чего бы начали?
А задачи я не увидел. Было абстрагирование от задачи с определениями её в терминах ООП. Об этом я уже упомянул выше.
Архитектуру лучше сразу закладывать конечную, но такую, чтобы можно было контроллировать развитие продукта на любой стадии. Я так понял Вашу цель. Для этого курим Итеративную Разработку. При том, что и архитектуру поначалу тоже не стоит продумывать досконально — только в общих чертах, кроме особо критичных участков. Т.е. если в одном модуле Вы продумали архитектуру и подтвердили её прототипами, то похожую архитектуру в другом модуле на первой стадии можно просто обозначить.
