Menu
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?
479
Dependency Injection (or inversion) is basically providing the objects that an object needs, instead of having it construct the objects themselves. It is a useful technique that makes testing easier, as it allows you to mock the dependencies.
Dependency injection (also known as DI) is a design pattern in which a class or object has its dependent classes injected (passed to it by another class or object) rather than create them directly. Dependency injection facilitates loose coupling and promotes testability and maintenance.
ASP.NET Core supports the dependency injection (DI) software design pattern, which is a technique for achieving Inversion of Control (IoC) between classes and their dependencies. For more information specific to dependency injection within MVC controllers, see Dependency injection into controllers in ASP.NET Core.
Dependency Injection is done by supplying the DEPENDENCY through the class's constructor when creating the instance of that class. The injected component can be used anywhere within the class. Recommended to use when the injected dependency, you are using across the class methods.
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.
177
Take a look at the Refix project on CodePlex. It stands for REference FIX and it works very nicely.
44
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
