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.
Related
When modularizing a grails application, when does it make sense to add the module as a plugin vs gradle dependency?
For Example:
akaDomain contains all the domain objects.
akaWebsites contains all the presentation logic.
akaService1 contains some services.
akaService2 contains some other services.
All the websites and services share akaDomain.
Can the domain classes present in akaDomain be used for scaffolding controllers and views in another application like akaService and akaWebsite?
Can this be achieved using plugins or dependency or both.
Please explain what am I missing if I don't make a plugin of akaDomain.
This answer uses plugin to explain how to modularize grails app.
You can definitely use the domains defined in one plugin as the basis for scaffolding in another plugin or in a main application. There are several practical considerations when doing so however:
If you choose to implement UI in a plugin, then you are committing to a UI look and feel that is to be shared across multiple applications. This is often very difficult when doing custom / contract development where every customer wants their own personal look and feel. You will want to think about selecting a UI abstraction as well that allows flexibility on theme support at least. We use Twitter Bootstrap for this purpose but there are several others that fit the bill.
You must manage the dependencies between the "domain/service" and the "UI" plugins. This is true of any plugin ecosystem, but once you commit to abstraction, this discipline is very important or you end up with dependency dead ends or cycles. It is a lot of work, but the pay off for productivity is very high.
As for the question on Grails Plugins vs Gradle dependencies:
Plugins are in fact Gradle dependencies (in Grails 3.x at least). That is, plugin dependency management is implemented on top of Gradle. Plugins provide additional support for integrating into a Grails application that include things like:
Automated spring bean registration and initialization at startup.
Participation in application component reloading.
Artefact definitions and initialization at startup.
So, implement using plugins and you get the best of both worlds.
I'll just preface this question by saying I began working with SignalR around 30 hrs ago, so please forgive any amateur questions and feel free to point me to the documentation that I've missed if you know of some. Also, I'm not trying to write a blog post - just explaining the steps I went through to get where I am.
TLDR? skip to the questions at the end...
I need to use the Sql Server Backplane (would love to use Redis but we don't currently deal with Redis and aren't comfortable introducing too many new technologies in one dev cycle). Currently, there isn't a NuGet package available for Microsoft.AspNet.SignalR.SqlServer so I have to work with the Github source.
So I went and pulled down the source, compiled and added the reference to Microsoft.AspNet.SignalR.SqlServer.dll but now compilation fails (specifically when referencing GlobalHost.DependencyResolver.UseSqlServer( ... ) in my code - it's a dependency conflict where the *.SqlServer code is expecting a more recent version of *.SignalR.Core - not really surprising as Github's version has (no doubt) more than a few changes since the NuGet package was released). :(
So the next step is to use the *.Core which I compiled with *.SqlServer. Next problem - the new SignalR version no longer works with *.Hosting.Common or *.Hosting.AspNet which have been replaced with the *.Owin library.
So, I added *.Owin (and Owin - from NuGet) but now I run into yet another problem: the MapHubs( ... ) extension method no longer works - there are extension methods called MapHubs( IAppBuilder builder, ... ) in Owin but they don't work off the RouteTable anymore - they work of Owin.IAppBuilder (hence the need to reference Owin, I suppose).
So this is where I'm at. I did a quick read-up about Owin (seems like a cool concept) but I don't particularly care to spend some hours getting my head around that just to be able to setup SignalR on the server-side. So, now for the questions:
Should I just try to make *.SqlServer play nice with the older NuGet packages of SignalR (in other words, is it likely that changing the dependencies of *.SqlServer will introduce unreliable behaviour)? Or, is there a version of *.SqlServer which works with the current NuGet release version of SignalR available online already?
What specific steps are needed to run SignalR via the Owin host approach (I can't find any examples for this without, say, Nancy integration thrown in - or is that the correct approach)?
What is the replacement approach for the MapHubs method? Where do I get an IAppBuilder from? Am I even supposed to do so?
In a Google Groups post, David Fowler indicates that, with Owin support, the AspNet dependency is no longer required. That's fine - but is there any reason to use SignalR in an ASP.Net MVC app now?
If no part of SignalR is hosted via IIS on the server, does client-side fallback (i.e. SSE or long-polling) go through IIS or does it use the Owin host independently?
Finally, I was planning to run SignalR off an ASP.Net MVC 4 project being hosted as a virtual directory off another existing site - I want to work within a single domain. With the Owin approach is it still feasible to do this when my site is hosted in IIS 7.5?
UPDATE: As per 1. above, I managed to get the code compiling by making *.SqlServer depend upon the current NuGet *.Core implementation. So now I can continue development. I don't think I want to use this in production though - I only had to make a small change relating to disposing an object - but I just don't think it's a good approach. So my questions around the Owin approach still stand - unless someone can convince me that the approach I've taken is fine.
Thanks,
Zac
Short Answer:
Hopefully this will help others out who have this problem (I'm sure there's at least one of you!): it seems that the question I asked was really badly timed as, a couple of hours after posting, SignalR was updated in NuGet to version 1.0.0-rc1. So, to anyone with the same problem I had - just upgrade the package.
Details:
After installing when you look at the references, you'll notice that there's now a Microsoft.AspNet.SignalR.SystemWeb reference. Without having delved into it yet, I'm thinking this is a replacement for *.Hosting.Common and *.Hosting.AspNet because after updating the MapHubs( ... ) extension method works fine.
I also noted that the *.SystemWeb reference depends on *.Owin - so I guess the Owin reference is used as an abstraction layer which allows the SystemWeb hosting to be independent of underlying IIS/other server implementations.
As for the .SqlServer reference, well, that still requires me to compile a version against the NuGet version of *.Core in order to compile locally. I'm going to just work with that for now and hope that the project team release a working version on NuGet sometime in the near-future.
A realistic alternative would be to convince my team that we should throw Redis into the mix - having worked with Redis on other projects, I consider this to be a good option due to performance considerations however it does require Linux which might be a problem for a .Net team...
I understand how to implement a StructureMap registry, my question concerns the fact that every project that contains a StructureMap registry requires a static reference to the StructureMap assembly. Is there a best practice for how to structure the configuration for a large number of projects (30+) without forcing each project to take this dependency?
The alternative, I suppose, would be to create a bootstrapper assembly that could be referenced by the host process. The bootstrapper would perform all wire-up. In this scenario, the bootstrap assembly, instead, would have references to all of the projects. This has the upside of centralizing the reference to StructureMap so that all of the projects are unaware of StructureMap.
Using XML-based configuration is not an option for me.
Are there any other options for configuration that minimize the number of static references the projects in the solution must take? I'm guessing that there isn't, but thought I'd solicit some other opinions.
Technically, you only need a single project to reference the container framework, and that is the top-level application project. It references all the other projects and specifies the configuration of the components.
This puts the entire graph configuration out of the hands of each project, opting instead to define graphs only where they are used. This gives each application the complete freedom to configure components, rather than assuming the components will be used in the same way every time (as is implied by the registries which are inherent to each project).
An aside that may or may not be useful: in quantum physics, when we observe a particle, we collapse it from every possible state into a particular one. Frameworks are similar, in that they don't exist in a single state until they are observed, which here means "put to use in an application." This frames the application as the observer, which is the context in which the framework collapses into a single form.
Now, I generally wouldn't want the application be responsible for both being a running application and also configuring that runtime. For this reason, I tend to have a Composition project which references the others as well as the container framework. The actual application project can then reference the Composition project. This externalizes the registries from each project, including the application project, producing a cohesive assembly whose sole purpose is to define the composition of a particular application.
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.
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):