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

Есть варианты

view.Update(Reason.Layout | Reason.Style | Reason.Grouping) — например если изменился лаёут, стиль и группировка

или же вводить отдельные методы для обновления соответсвующих частей, типа

view.UpdateLayout();
view.UpdateStyle();
view.UpdateGrouping();

Какой вариант предпочтительнее ? Какие есть еще возможности ?

Здравствуйте, Tanker, Вы писали:

T>Какой вариант предпочтительнее ? Какие есть еще возможности ?

Не нужно пинать view для обновления. Она должна привязываться к модели:

public interface LayoutModel {
  public void addChangeListener(listener : LayoutModelListener);
  public void removeChangeListener(listener : LayoutModelListener);
}

public interface StyleModel {
  public void addChangeListener(listener : StyleModelListener);
  public void removeChangeListener(listener : StyleModelListener);
}

public interface GroupingModel {
  public void addChangeListener(listener : GroupingModelListener);
  public void removeChangeListener(listener : GroupingModelListener);
}

public class View {
  public View(layout : LayoutModel, style : StyleModel, grouping : GroupingModel) {
    ...
  }
}

Вся логика работает с реализациями моделей, может устанавливать в них данные и т.п. С view логика не работает вообще. Все изменения проходят через события, на которые подписан view. Ну а view по событиям уже обновляется. Если же управлять вручную, можно где-нибудь забыть обновить view и наступит рассинхронизация моделей и отображения.

Здравствуйте, maxkar, Вы писали:

M>Не нужно пинать view для обновления. Она должна привязываться к модели:

Вьюшки активные, модель пассивная. Это в силу того, что сложно получить внятные уведомления от модели т.к. структура слишком сложная.

Здравствуйте, Tanker, Вы писали:

T>Winfoms приложение, есть вью которая подтягивает и отображает очень много информации, сразу целую пачку источников. Нужен подходящий способ обновления этой вьюшки.

Вот такой вот MVC

Здравствуйте, Tanker, Вы писали:

T>Вьюшки активные, модель пассивная. Это в силу того, что сложно получить внятные уведомления от модели т.к. структура слишком сложная.

Тем более упрощать нужно. Иначе вероятность того, что кто-то где-то забудет обновить данные, возрастает. Да, обновления не обязательно должны быть внятные — они вполне могут "огрубляться" до простого "а данные сменились" (без подробностей, кто, где и насколько). Можно даже так:

public class Layout implements LayoutModel {
  public void beginChange() {};
  public void endChange() { fire(new LayoutChangedEvent()) };
}

В begin/end можно проверять "наличие" операции. В конце концов, у вас же модель все равно конкретная. Сделайте "грубое" уведомление + подписку в модели (хоть банальный fireModelChanged вместо двух методов). Ну и запускайте эту рассылку из модели в контроллере. У вас будет service, затем fireUpdated, и уже из модели modelUpdated во view. Потом можно будет пробовать и от такого "уведомления" избавиться и создавать из операций обновления модели и ее частей, например. Или оформится операция обновления модели (с началом/концом и некоторыми проверками корректности) для "пакетных" операций (в лог можно писать, если beginChange вызывается без endChange).

Можно еще называть вещи своими именами:

view.SetLayout(Layout layout);
view.SetStyle(Style style);
view.SetGrouping(Grouping grouping);
//или
view.ApplyLayout(Layout layout);
view.ApplyStyle(Style style);
view.ApplyGrouping(Grouping grouping);

В качестве глагола, возможны и другие варианты. Например, Use. Смысла хранить "пассивную" ссылку на модель не вижу. Пусть обновляющий явно передает "актуальную" модель (даже если ссылка на нее не менялась). Правда, очень желательно, чтобы вне этих методов view не лазил в соответствующую модель (копировал необходимые данные, например). Иначе возникает вопрос о том, как поведет себя View, если я данные изменю а метод не вызову, например. Так что если изменение layout после вызова view.setLayout может изменить где-то вид UI, я бы этот подход применять не стал. При таком подходе связь между "UI" и моделью не прослеживается, но у вас ее и так нет.

Здравствуйте, maxkar, Вы писали:

M>Тем более упрощать нужно. Иначе вероятность того, что кто-то где-то забудет обновить данные, возрастает. Да, обновления не обязательно должны быть внятные — они вполне могут "огрубляться" до простого "а данные сменились" (без подробностей, кто, где и насколько).

Нужны именно внятные обновления с целью оптимизации.

>Можно даже так:
M>

M>public class Layout implements LayoutModel {
M>  public void beginChange() {};
M>  public void endChange() { fire(new LayoutChangedEvent()) };
M>}
M>

M>В begin/end можно проверять "наличие" операции.

Спасибо, ты подсказал отмерший вариант — отмерший. Проблема с такими обновлениями в том, что нет возможности узнать границы изменений. Только для некоторых операций можно точно сказать, что же нужно обновлять.
То есть, на примере, что бы вычислить, что изменения именно в Layout надо приседать от забора и до обеда. Зато для некоторых операций точно известно, что они затрагивают только Laouyt. Соответственно смысла в LayoutModel нет никакого, хотя lauyout в наличии.
Еще пример попроще — удаление объекта может ничего не затроноть, а в другом разе такое же удаление того же объекта может затронуть буквально всё. Потому отслеживать лаеут я не собираюсь ибо это безумие, что и показал предыдущий опыт. Зато если я знаю, что этот объект изменил подпись, то я меняю только это и хочется что бы такие операции ровно ничего не стоили.

Если нет предложений по теме — не пиши, ок ?