Продолжу тему

Автор: Shmj
Дата: 30.09.17

, но конкретизирую.

При всем многообразии способов реализовать GUI, можно выделить несколько подходов:

1. Императивный подход. Каждый элемент создаете в коде (Button b = new Button()) и в том же коде устанавливаете свойства. Императивный подход не так так плох, когда есть хороший визуальный редактор и он выполняет за вас всю грязную работу (однако написание такого редактора -- задача не тривиальная).

2. Декларативный подход + лапша-код. Этот в старом стиле писали jsx, asp или php-страницы. Когда GUI задается декларативно, т.е. вы пишите все <div> <img>, но динамика осуществляется с помощью подмешивания в html спец. тегов (абстрагируемся от технологий, теги могут быть и клиентские <script>).

3. Разделение декларативного GUI и кода. В ASP.Net это не плохо сделали, старые aspx-страницы.

Элементы пишем декларативно с помощью HTML/XAML/etc. Чтобы манипулировать элементом, ты ему задаешь ID. И уже из кода по событию манипулируешь.

Элементы отображения табличных данных, как правило, все таки биндятся к данным, так как из кода задавать соответствия не удобно.

Я бы не сказал что подход такой уж плохой. Основной минус -- сложно тестировать код.

4. MVP. Чтобы подход 3 можно было тестировать, придумали MVP. Добавляем посредника, который управляет и формой (представлением) и View. Фишка в том, что мы сможем подменить форму на тестоый оъект, поскольку в форме ничего сложного не содерижится (форма не знает о методах презентера и данных View). Это все решает вопрос тестирования.

5. MVC. Типа альтернатива MVP для Web-а без JS, где нет событий (презентер то требует событий от View, а их нет в клиент-серверном старом взаимодействии (без WebSocket)).

В теории можно даже подменить одну View на другую, сделанную совсем по другой технологии (типа использовать вместо Web -- нейтивное приложение). Ведь код контроллера не знает кто и как его долбанную модельку будет отображать.

Популярна для Web-а, так как подходит под идеологию -- 1 запрос 1 ответ (1 объект модели отправили, новый объект модели приняли). Когда обмен данными двунаправленный, выходит на сцену MVVM.

6. MVVM. Фишка в двунаправленном байндинге. Т.е. есть некая модель и то что ты установишь в коде для этой модели -- отобразится в GUI. Но в отличии от MVC, можно еще и изменить свойство в модели и это отобразится в GUI.

Это удобнее и понятнее MVC, но не везде реализуемо (для браузера можно сделать только на стороне JS).

Ничего не забыл? Какой подход, по вашему, наиболее удобный?