Шаблон проектирования для обработки многих параметров и бизнес-правил

Question

Я работаю над проектом, который отвечает за создание «задания», состоящего из одной или нескольких «задач», которые сохраняются в базе данных через DAL.Столбцы задания и задачи состоят из значений, которые установлены в соответствии с бизнес-правилами.

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

Чтобы еще больше усложнить ситуацию, необходимо представить список заданий, и его следует вызывать в различныхпути (в виде ссылочной сборки, через службу Windows или через веб-службу).

Вот несколько примеров того, что он делает:

• Создание оценки стоимости работы
• Регистрация учетной записи и / или пользователя, которому назначено задание
• Создание события для отслеживания хода выполнения задания
• Объединение данных из внешнего пользовательского списка (.csv, .xls, ect.)
• Копирование файлов с локального диска на сетевой диск (при необходимости)

Мой вопрос: каковы лучшие практикиЛьды или шаблоны дизайна, чтобы сделать это как можно более простым и понятным?

Answer 1

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

Answer 2

Этот тип программ может стать очень запутанным, если его не содержать в чистоте с нуля. Я сам всегда стараюсь придерживаться базового 3-уровневого приложения (презентация, бизнес, данные). Существует много полезной информации для создания приложений подобным образом, и лучше всего сделать некоторые демонстрационные проекты и прочитать, что другие скажут по этому вопросу. Вот ссылка MSDN .

Мне самому пришлось перепроектировать приложение, которое делало что-то очень похожее. Как только я отделил свой Data Layer от всего остального, моя жизнь стала намного проще.

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

Answer 3

Кроме того, что я рекомендую использовать SOLID и делать все возможное, чтобы сохранить его СУХОЙ, я предлагаю ввести концепцию правил в систему.

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

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

Что касается SOLID, я рекомендую проверить электронную книгу здесь и попытаться сохранить подход развивающегося кода.

Answer 4

Учитывая ваше описание требований, нет никакого реального "простого" способа сделать это. Его требуемая функциональность огромна и разнообразна. Мои единственные предложения - сделать все это в библиотеке DLL (или даже в наборе DLL), чтобы разделить различные интерфейсы так, чтобы ссылки на сборку не требовали службы Windows (например); и придерживаться основных заповедей ООП, таких как слабая связь.