在 .NET 中管理依赖关系树的最佳方法是什么？
在我的上一个项目中，我们使用 MSBuild 作为脚本语言。 （是的，真的！）我们还为在 C# 中更有意义的部分编写了数百个自定义 MSBuild 任务。 （我什至编写了一个 MSBuild 任务来生成 MSBuild 任务的样板代码。是的，它消耗了自身。）
虽然我不建议其他人采取相同的方法，但我发现非常有用的事情之一是内置的依赖管理。 正如您所期望的，表达依赖关系并让 MSBuild 负责满足它们是很容易的。 例如，我们软件中的几乎每个步骤都需要将一组特定文件复制到特定位置。 你可以很容易地写：
Step1: CopyFiles
Step2: CopyFiles, Step1
当你执行Step2时，它只会复制文件一次。
构建并满足依赖关系树在软件中非常常见。 我希望 MSBuild 团队能够获取他们的依赖管理代码，将其与 MSBuild 解耦，并将其移至任何人都可以使用的 .NET Framework 中。 除此之外，您认为以这种方式管理依赖项的最佳选择是什么？
In my last project we used MSBuild as a scripting language. (yeah, really!) We also wrote hundreds of custom MSBuild tasks, for the parts that made more sense in C#. (I even wrote an MSBuild task to generate the boilerplate code for an MSBuild task. Yes, it consumed itself.)
While I don't recommend anyone else take this same approach, one of the things I found very helpful was the built-in dependency management. As you'd expect, it was easy to express dependency relationships and let MSBuild take care of satisfying them. For example, almost every step in our software required that a certain set of files be copied to a certain location. You could easily write:
Step1: CopyFiles
Step2: CopyFiles, Step1
and when you execute Step2, it would only copy the files once.
Building and satisfying a dependency tree is a pretty common in software. I wish the MSBuild team would take their dependency management code, decouple it from MSBuild, and move it in to the .NET Framework where anyone can use it. Baring that, what do you think is the best option for managing dependencies this way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为你可以使用像 Spring 这样的 IOC 容器来获得这种行为。
实例化任何只能作为单例运行一次的任务，并让任务对象的构造函数运行该任务。 然后，稍后出现的对该任务的依赖项的任何对象都将获得对已运行的任务的引用，并且能够获取该任务的结果，或者能够推断该任务已经成功运行。
在 spring 配置中，您最终会看到许多任务链接在一起，每个任务都在其构造函数配置中引用其他任务。
这种方法是最灵活的，您不会受到“任务”或任何过于繁重的事情的限制。
我猜任何工作流程库也有类似的概念。 但我对这些并不是很熟悉。
我认为对于任何较小的东西，人们必须使用访问者模式以及可能使用字典来保存状态来滚动自己的对象图和界面。
I think you could use an IOC container like Spring to get this kind of behavior.
Instantiate any task that must only run once as a singleton and have the constructor of the task object run the task. Then any object that comes along later with a dependency on that task will get a reference to the task that already ran and be able to get the results of that task or be able to infer that that task has already been run successfully.
In the spring config you would end up with many tasks chained together, each one references other tasks in its constructor config.
This approach is the most flexible and you are not restricted to "tasks" or anything too heavy for that matter.
I'm guessing any workflow library also has similar concepts. But I am not really familiar with these.
I think for anything smaller, people must just roll their own object graph and interface using the visitor pattern and maybe a Dictionary to hold state.
查看 CodePlex 上的 Refix 项目。 它代表 REReference FIX，并且效果非常好。
Take a look at the Refix project on CodePlex. It stands for REference FIX and it works very nicely.