MVC для настольного приложения без слоя данных

Question

Вопрос может быть сложным (из-за его природы или моего способа его описания), поэтому действительно прочитайте это, прежде чем отвечать.

У меня есть это приложение, чтобы написать:
а) настольное приложение;
b) нет уровня данных в смысле базы данных, файлов или любого другого хранилища (нет необходимости сохранять, хранить или загружать данные);
в) в приложении будут реализованы некоторые алгоритмы вычислений (генетический алгоритм);
б) предоставляет графический интерфейс, который будет отображать элементы управления для приложений и результатов вычислений.

Я думаю об использовании шаблона MVC, но у меня есть сомнения, как его использовать. Поскольку у меня нет уровня данных в смысле (например) базы данных (данные генерируются во время выполнения на основе пользовательского ввода), я обеспокоен способом использования MVC в этой реализации. До сих пор я придумал два подхода:

1. GUI - это вид. Генетический алгоритм является контроллером. GeneticAlgorithmResults - это Модель (как класс, который хранит только данные). Основной поток:

   • Вид отправляет пользовательский ввод в контроллер;
   • Контроллер обрабатывает пользовательский ввод и генерирует данные;
   • Контроллер отправляет сгенерированные данные в Модель;
   • Модель уведомляет Представление о новых данных;
   • Вид извлекает новые данные и обновляет дисплей.

2. GUI - это вид. AppEngine - это контроллер. Генетический алгоритм и Генетический алгоритмРезультаты являются моделью. Теперь у нас есть:

   • Вид отправляет пользовательский ввод в контроллер;
   • Контроллер обрабатывает вводимые пользователем данные и отправляет управляющие сигналы на модель.
   • Модель обновляет свое внутреннее состояние (генерирует новые данные);
   • Модель уведомляет Контроллер о новых данных;
   • Контроллер извлекает данные в модель;
   • Контроллер обрабатывает данные;
   • Контроллер отправляет обработанные данные в View;
   • Вид обновляет дисплей.

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

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

Какой подход вы бы порекомендовали? Или, может быть, я должен смешать их и использовать архитектуру первого подхода с потоком связи из второго подхода? Или какой-то другой дизайн?

Answer 1

Из моего понимания MVC вторая версия больше похожа на строгую парадигму MVC. Тем не менее, один из моих очень умных учителей однажды сказал мне, что шаблоны проектирования предназначены для того, чтобы дать свободный набор руководящих принципов, и не обязательно должны соблюдаться в T.

На мой взгляд, сочетание обоих - хорошая идея. Если какая-то логика заканчивается в модели, это не конец света, это просто означает, что вы должны быть более осторожными в отслеживании разделения ваших компонентов. Если небольшая модификация MVC сделает вашу жизнь проще на 50% (меньше накладных расходов на сообщения), то это, вероятно, хорошая идея.

Answer 2

Я бы определенно подошел к чему-то ближе ко второй реализации. Да, кажется, что больше сообщений передается взад и вперед, но если ваше приложение растет и изменяется, вы будете рады, что вы создали приложение с небольшими классами.

Подумайте: где логика для решения таких рутинных задач, как переключение между алгоритмами, их выполнение и обработка данных для просмотра?

Генетические алгоритмы работают с некими входными или исходными данными, не так ли? Вы получите это из слоя доступа к данным. Вам не нужны начальные данные или условия инициализации? Как насчет сохранения ваших результатов в файл и получения их для последующего просмотра? Я думаю, что вам нужно сделать это после того, как ваше приложение созреет. Ожидайте, что сначала вы будете использовать постоянство на основе файлов. Если вам это нравится, позже вы можете перейти на базу данных. Если вы создаете код на уровне абстрагированных персистентных данных, вам не придется менять бизнес-логику позже, чтобы поддержать переход от файла к базе данных.

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

Бизнес-уровень увидит ISolver, который принимает входные данные, и вы вызовете mySolver.Solve (). Вы должны иметь возможность переключаться между различными версиями, не изменяя логику своего бизнес-уровня ( Открытый закрытый принцип ). Единственное различие в том, как бизнес-логика должна взаимодействовать с алгоритмами, должно заключаться в конструкторе, и даже там вы должны рассмотреть использование шаблона Factory.