Какой лучший способ управлять деревом зависимостей в .NET?

В моем последнем проекте мы использовали MSBuild в качестве языка сценариев. (да, действительно!) Мы также написали сотни пользовательских задач MSBuild для тех частей, которые имели больше смысла в С#. (Я даже написал задачу MSBuild для генерации кода шаблона для задачи MSBuild. Да, он сам потреблял.)

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

Step1: CopyFiles
Step2: CopyFiles, Step1

и когда вы выполняете Step2, он будет копировать только файлы один раз.

Создание и удовлетворение дерева зависимостей довольно распространено в программном обеспечении. Я хочу, чтобы команда MSBuild взяла свой код управления зависимостями, отделила его от MSBuild и переместила в .NET Framework, где любой может ее использовать. Если вы считаете, что , как вы думаете, лучший вариант для управления зависимостями таким образом?

Ответ 1

Я думаю, вы могли бы использовать контейнер IOC, например Spring, чтобы получить такое поведение.

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

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

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

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

Ответ 1

Ответ 2