Traditionally, adding dependency injection with any standard injection package to an MVC solution would normally mean that you would have to write a Controller Factory and wire it up in your Application_Start() method.
If you want to add dependency injection into an MVC solution, just add one of the pre-baked nuget packages that does the MVC wire up for you:
In this previous post I outlined why if you were considering shared hosting, you should avoid Eukhost.
I am writing this post as an urgent warning to anyone currently hosting with Eukhost, or considering hosting with Eukhost. Your data is at risk of being compromised.
Because of a mistake made by Eukhost’s support staff, I am now in possession of 6 databases that I do not own. All of these databases contain sensitive information, including email addresses, residential addresses, and unencrypted passwords. Here’s a screenshot:
I came into possession of these databases as I was terminating my hosting with Eukhost. As part of this process, I asked Eukhost to back up and email me my databases. They responded with a link to a zip file that was supposed to contain my databases. This is where their support staff messed up – they backed up the wrong user’s databases.
Obviously this is a huge violation of data protection practices – but it also puts the owner of the other databases in a horrible positon. All of their user data has been compromised through no fault of their own.
My advice if you are considering Eukhost: Avoid them.
My advice if you are currently hosting with Eukhost: Close your account now and order them to delete your data.
With the upcoming release of asp.net 4.5, which includes the fantastic looking ASP.Net Web API, many of us will be thinking that this almost stands on the toes of WCF slightly.
Well not quite.
The two really can serve very different purposes.
WCF is designed so that all of your connectivity and endpoints are abstracted away from the core operations of the service (Although you may need to apply certain attributes to your operation contract)
All of the connectivity and endpoint data is largely configured through the Web.Config file (and you really should be read up on what your settings do before trying to tweak them)
WCF therefore allows you to switch out endpoints and connections through the Web.Config file without the need for recompiling (for example, if you wanted to disable SOAP on a SOAP and JSON web service)
That’s a lot of power.
So the question is, what if my intention is to only ever create a RESTful webservice and I never need to support other message types (such as SOAP)? Should I be using WCF?
Well, the short answer is that you can, but you’d be using a sledgehammer to crack a nutshell. Another major factor will be the issue that WCF doesn’t really let you go all the way with REST very easily:
All WCF requests for webHttpBindings are steered towards only using GET [WebGet] and POST [WebInvoke]
Enabling other HTTP verbs can involve configuration of IIS to accept request of that particular verb on .svc files
I’m a big fan of the KISS principle. So if you are going to setup a Web Service and don’t need SOAP, you should take a good look at the ASP.Net Web API.
But what do the experts say?
Well, Christian Weyer, who basically had a hand in WCF’s inception, states in this blog post that the web is going in a new direction, focused around lightweight web based architectures. He is leaning toward using the ASP.Net Web API for these sorts of architectures.
apigee have made a fantastic ebook on Web APIs available to download for free. It’s a great read, and got me thinking about web services in more detail.