Дизайн высокого уровня для установки и обновления приложения - PullRequest
0 голосов
/ 07 марта 2009

Мне нужно написать очень простое приложение WinForms, но я часто зацикливаюсь на них. Я застрял в циклах «Да», «Нет», «Повторить попытку», и, не задумываясь о действиях приложения, я начинаю думать о «рабочем процессе» приложения. Должен ли я просто иметь метод для каждой задачи и вызывать каждую последовательно после проверки, что предыдущий не поднял флаг 'abort'?

Должен ли я реализовать простой интерфейс ITask и класс для каждой задачи, а затем перебрать упорядоченную коллекцию задач? Должен ли я использовать это как простое введение в Windows Workflow? Сфера применения этого приложения и его набор задач гарантированно возрастут, поэтому мой первый вариант жесткого кодирования задач - самый неприятный, но, учитывая размер приложения, обслуживание довольно легко выполнить, просто изменив код; исполняемый файл всегда разворачивается с материалами обновления, а не разворачивается постоянно.

Ответы [ 3 ]

1 голос
/ 08 марта 2009

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

Я бы пошел по пути ITask за его гибкость (по сравнению с простыми методами), но в то же время простой. Я чувствую, что это также поможет вам с модульными / интеграционными тестами. Тем не менее, я рекомендую следить за повторным использованием задач, таких как, скажем, задача перемещения файла, поскольку вы не хотите заканчивать множеством задач, которые делают то же самое. Просто сделайте это на этапах рефакторинга, чтобы позволить фактическим потребностям / использованию определять, что вам нужно (в тестах - TDD:)).

0 голосов
/ 07 марта 2009

Я собираюсь добавить к предложению Питера, сказав: «У простой вещи может сработать , что также является хорошим дизайном ».

Бывают случаи, когда «простейшая» вещь является также самой глупой, с точки зрения дизайна, и это вызовет горе в будущем, что является противоположностью того, что преследует мантра Extremem Programming.

Ваш второй вариант звучит прямо для меня. Он прост в реализации, имеет хороший дизайн и облегчит обслуживание в дальнейшем.

0 голосов
/ 07 марта 2009

Сделай самое простое. Вы всегда можете выполнить рефакторинг позже.

...