Коронарография: продолжение

Основные архитектурные решения

Формат обмена данными с .NET

С первого взгляда понятно, что данных будет много и их структура будет не тривиальной. Выбирали:

• Придумать свой простой xml-формат и общаться с .NET через него.
  • можно придумать очень простой и удобный для обработки формат
  • объем этого представления данных будет заведомо меньше любого другого
  • логика обработки (сериализация/десериализация) будет и во Flash, и в .NET

• Воспользоваться тем, что в .NET модель предметной области (сосудов, частей сосудов и пр.) уже создана и использовать для нее стандартных механизм сериализации в xml (по-моему там их несколько, был взят самый простой)
  • на стороне .NET обмен становится очень простым и на порядок более устойчивым к изменениям - нужно менять только саму модель
  • не нужно придумывать велосипед - свой формат данных
  • он заведомо не содержит ошибок
  • в случае изменений в модели формат меняется сам
  • данные в таком виде занимают на порядок больше места, чем в самодельном
  • логика его обработки остается, но только во Flash

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

Попытка использовать паттерн проектирования Model View Controller

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

Даже если вы не знакомы с MVC, из названий его частей достаточно ясно, что они должны делать. То, что изображено на рисунке, это даже не MVC - скорее Model View Presenter, но этого названия получившаяся конструкция тоже не заслуживает.Результат грамотного применения MVС - это разделение внешнего вида и логики, логики представления и бизнес-логики, защищенность системы от внешних изменений. Модель была реализована хорошо, она заключала в себе описание предметной области (сосуды, перетоки и пр.) и алгоритмы работы с ней (бизнес логику), предоставляя интерфейс для воздействия. Эта часть работы была самой большой и лучше всего сделана, дальше пошли ошибки.

• Модель сама вызывала функции как View, так и Controller
• Controller содержал просто перевызывал функции, запрошенные у него моделью, из View
• Controller содержал только логику работы со внешней средой, вся логика представления была во View
• View внутри себя не смог нормально организовать логику представления
• …

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