Do any inversion of control / dependency injection framworks support viewing the object dependencies that have been registered? This is not to execute the code, but to better understand it. It seems that a graph based on the information it has (class A depends on B and C, class B dependencs on C and E, etc) would really document a system well.
I'm using Castle Windsor at the moment, but wouldn't mind trying a different framework for this functionality.
For Spring the Spring IDE shows you a dependency graph.
For Guice you can use Grapher.
Here's a little console application that'll output the dependency graph of a Windsor container. Text-only, but still very useful.
I recently blogged about showing all component dependencies as a proper graph. Sample output (scaled down):
Related
I have made a project in Umbraco using backoffice completely.But Now I am trying to apply concept of dependency injection(which I may have used in past..but not by that specific name) in that project.
and after loads of searching.I now know the concept of dependency injection(I think),in which we are supposed to use classes and constructor to restrict the input supplied to a function in terms of type,value.
But how am I suppose to make that umbraco project from that.I once tried making a strongly typed.It looks much like that which I am supposed to do now.
I also took reference from these articles.
Is it possible to use dependency injection with Umbraco 7 ContentService event handlers?
Why does one use dependency injection?
But still I am kind of stuck..Is there any other way to do unit testing in umbraco.
Yes, you can! :)
Basically, the starting URL for using IoC and DI with Umbraco was already shared. It's here: https://our.umbraco.org/documentation/reference/using-ioc. You can of course use any of the avaialable containers, the example is just for autofac. You just need to remember to initialize container when Umbraco starts (using event handlers).
For Unit Testing resources I would point you first to tests made by Umbraco itself: https://github.com/umbraco/Umbraco-CMS/tree/dev-v7/src/Umbraco.Tests. You can explore how the core team is testing their code and even reference this library and make use of it in your solution.
There are some other useful materials to start unit testing with Umbraco. To list a few:
http://blog.aabech.no/archive/the-basics-of-unit-testing-umbraco/
http://skrift.io/articles/archive/unit-testing-umbraco-plausible/
http://skrift.io/articles/archive/unit-testing-umbraco-with-umbraco-context-mock/
https://www.youtube.com/watch?v=1xS002NyGnc
I think it will be enough to start doing it.
I am integrating Hangfire into an application (MVC5 4.6) in order to schedule a daily synchronisation task that is normally triggered by an admin user every evening.
The problem is, I can't seem to get Hangfire to play nice with my current Ninject setup. It won't just run a function itself and I needed to install Hangfire.Ninject package and register the kernel in Startup.cs.
The problem is, I have dependency A which contains dependency B, but dependency B also contains dependency A (cyclical).
As these are declared inRequestScope in the Ninject kernel set-up, this hasn't caused any issues, but this particular item is used so much throughout the application it would be far too painful to try and remove the cyclical dependency, but for some reason Hangfire won't accept it.
Are there any alternatives to removing the cyclical dependency?
I still haven't quite avoided the issue completely, but for Hangfire purposes I decided to register a different Ninject Kernel and could customise what I needed precisely.
Most dependencies work now using .InBackgroundJobScope() rather than .InRequestScope() (from the Hangfire Ninject nuget package), but oddly a few others (which luckily I don't need) still give me the cyclical dependency issue.
I am new to WebJars and so far have failed to see any real advantages that they bring to the table compared to simply using Bower for example. What justifies the idea of putting frontend JS into backend JARs?
Please name at least one or more "objective" advantages to using WebJars.
WebJars are useful when you have a JVM-based project and you want to use only one dependency manager / build tool.
When using a dependency injection container, missing dependencies are detected when you execute resolve. This is at runtime.
This article describes a partial solution. It would help simplify test, debug, and maintenance, but it still requires tests to be executed to validate your behavior (especially if you use the abstract factory sub-solution for runtime resolution):
http://blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx
When using dependency injection containers, is there a way to determine at statically that all of your dependencies will be resolved?
The Managed Extensibility Framework (MEF) can do this. There are some best practices that you need to adhere to in order for the analysis to be accurate, but the results are otherwise good.
To analyse a set of assemblies a command-line tool is used - see http://blogs.msdn.com/b/nblumhardt/archive/2009/08/28/analyze-mef-assemblies-from-the-command-line.aspx. This can be run from Visual Studio or a build script in a continuous integration server - http://blogs.msdn.com/b/nblumhardt/archive/2009/09/24/debug-composition-from-within-visual-studio.aspx.
You can do it visually (again over a set of assemblies) using the MefContrib project's Visual MEFX - see http://xamlcoder.com/blog/2010/04/10/updated-visual-mefx/
MEF supports this functionality by being both very declarative (standard attributes for configuration) and by using an underlying composition model that works lazily (it can build the graph without creating any instances... Takes a bit to wrap your head around.)
Short answer: no, it can't be done.
Doing this would require being able to represent all components and their dependencies (the container metadata) as a graph, in order to analyze it. Problem is, the more sophisticated the container, the harder it gets to achieve this. Take for example Windsor. Its numerous extension points make the dependencies too dynamic to be represented as a graph. Lazy component loaders, handler selectors, factories, componentmodel contributors, subresolvers, all participate in the process and they can be arbitrary user code, which makes it impossible to analyze statically.
A static analysis might be feasible for a trivial container, but then this hypothetical container would be pretty useless for real-world projects.
So as usual it's a trade-off, and the best we can do is have some tests that exercise the actual resolution of all registered components in the container. StructureMap has a AssertConfigurationIsValid() method to do just that.
Even so, there could be more subtle errors that are not caught by this, such as lifestyle issues.
In addition to what Mauricio said, Windsor 2.5 has a feature that you might find useful when diagnosing issues with missing dependencies or just looking through the components in the container.
I blogged about beta version of it here. It's now quite more useful and as everything in Windsor - it's extensible so you can out your own items on that list.
Maybe not with a dependency injection container. However, you can do dependency injection manually, without a container. For example:
var foo = new Foo();
var bar = new Bar(foo);
var program = new Program(bar);
program.Run();
If it compiles then all the dependencies are there.
However, trouble looms as soon as the dependency graph grows large enough that you can't keep it entirely in your head (espcially with some circular dependencies thrown in the mix). If you do refactorings that involve rearranging of dependencies, then it will become hard work to adapt the order of constructor calls.
I'm working with dependency injection (DI from now on) to resolve components and am looking for an elegant solution to loading dependent assemblies in a .NET environment. As an explanation, lets say that we have 3 assemblies, A, B and C, where A depends on B and B depends on C. Now I need to load components from assembly A, but because I am using DI, I don't have a reference to assembly A. And even a reference to assembly A wouldn't be enough because I somehow need to ensure that A, B and C all end up in my output directory.
So, some obvious solutions are to:
- add references to A, B and C from the executing application: Requires knowledge of the dependency structure which, in my case, is extremely complex, making this a somewhat undesired solution.
- add these dlls to the GAC: Just not an option in my case.
So I'm wondering if anyone has an elegant solution to this issue. Not sure if it's relevant but I'm using Castle Windsor for DI.
Thanks
Joni
There is an event called AssemblyResolve on your AppDomain that gives you a chance to load missing assemblies. This lets you load your missing assembly from any stream you provide such as a file in a different folder or a file stored in a database.
What would it buy you to load the assemblies dynamically?
You should just add references to A, B, and C in the executing application, unless you're writing an application designed to be extended by other parties, or you have to change the dependencies extremely frequently.
Otherwise, you're solving a trivial problem (the need to recompile to deploy changes) by introducing a different problem (the possibility of failing at runtime).
Think of the list of references as your application's constructor arguments - your application should clearly declare its dependencies instead of tucking them away in a config file.
If the only issue you have is getting the assemblies in the output directory than it's not a Windsor question - it's a MsBuild question (or NAnt or whatever you're using to build your project). Just have your script do it.
If you're looking at extensibility scenario, that is you have the assemblies in the directory and you want to load them, Windsor 2.5 (current trunk) has some pretty nice support for this as well, both from XML and from fluent API.