I am looking for an ioc container to use for asp.net webapi. Couple of the key feature we are looking for are as follow
Custom lifetimes
Built-in support for web request lifetime
Good integration with web api in terms of manage the dependency registration.
Mark Seemann knows his DI/Ioc and has an article on implementing it for Wep Api with Castle Windsor here. I don't know about custom lifetimes but it definitely solves the second and third requirements.
Castle is not as lightweight as say Autofac but it's been around for years and is tried and tested: I am using Castle for my Web Api and Mvc projects without issue so far.
Both should do the job though.
I personally like Unity. The reason why I use Unity is that it is build by Microsoft and with that you can expect that it is nearly up-to-date. Also I had prior experience with it and it has good support for ASP.NET Web API, but the final choice for or against a container is up to you. It really dependent on personal flavor.
There's a small part in the ASP.NET tutorials which talks about using Unity with Web API.
Related
So much I could understand, Kephas does not provide its own DI container, but it builds adapters on existing ones (Kephas has its own dependecy injection container. Why another framework, why not use an existing one?). Existing adapters are for System.Composition (MEF2) and, as I learned recently, for Autofac (starting with version 6.5.0, Cannot use constructors in open generic services with Kephas).
However, ASP.NET comes with its own implementation of a DI container. In this regard, is it possible to use Kephas with ASP.NET Core now, and if yes, how?
Starting with version 6.5.0, Kephas will provide also an ASP.NET Core adapter so, yes, it will be shortly possible to use Kephas with ASP.NET Core. However, the built-in Dependency Injection does not have all the features Kephas requires, naming metadata and lazy instantiation. There will also be an adapter for Microsoft.Extensions.DependencyInjection, but without the aforementioned functionality, so I do not really recommend it. The Autofac adapter is the recommended one (event the Microsoft ASP.NET Core recommends it for advanced scenarios).
On the other hand, you could let Kephas manage its dependencies using MEF2 or Autofac and provide to ASP.NET Core a service provider aggregating the default one (or the one of your choice) and the one from Kephas. This has the following drawbacks:
You will end up with two containers.
The Kephas container will not have access to the services provided by ASP.NET Core.
Windows Identity Foundation (WIF) is around for a while, may be 5 to 7 years or more!, now Microsoft made WIF part of .net framework (4.5) itself. As we know WIF is a middleware for building identity aware applications.
As the trend on the web technology is changing, we have now need to incorporate multiple other identity providers (Google, Facebook etc.), in our application.
Now the industry got other Middleware technologies like OWIN, ASP.NET Identity etc.,
My Question,
Is still the WIF relevant and do we need to consider using it for new projects?
Or
Do we need to implement OWIN as alternative middleware? (As I understand Microsoft is betting on OWIN / KATANA moving forward).
Please share your thoughts.
For new projects I highly recommend considering Katana and ASP.NET 5 OWIN middleware.
WIF remains supported as part of the .NET framework, however we stopped adding new features long ago - all the innovation has been poured in Katana and OWIN middleware in general. Also, we like to think that the OWIN middleware is significantly easier to use :) Again, if your project has legacy aspects that impose the use of WIF, you can go ahead knowing we'll support you: but if you have any chance of choosing, the OWIN middleware is the best path moving forward.
Totally agree with #vibronet but to answer the question - yes - still relevant.
There's a ton of WIF out there - I support lots of customers who still use it.
OWIN is easier to use but the nice thing about WIF is that everything is in the web.config so the details are more explicit and easier to change. However, that comes at the cost of a fairly steep learning curve.
Refer: OWIN : Differences with WIF and WIF : Wrappers around protocols.
As per the links:
"You can think of OWIN as MVC and WIF as Forms. Forms are still supported but all the new whizzy features and all the code samples relate to MVC.
It's important to note the neither OWIN nor WIF are protocols - they are the wrappers around the protocols. The protocols underneath both are identical."
Also consider we have moved some of the functionality of WIF into an open source project we refer to as Wilson. You can check it out here: https://github.com/AzureAD/azure-activedirectory-identitymodel-extensions-for-dotnet
i need few reason for which people mixed ASP.Net MVC and web-api in same project. when we can develop a full project in mvc only then why web api need to include. also we can host webapi project separately which can server request to MVC and other devs or mobile devs etc.discuss the reason and advantages.
some one answer :
We have recently built a project within MVC and WebApi, we used the WebApi purely because from a Mobile Apps perspective. We allowed the mobile dev guys to call our methods within our MVC application instead of them having to go and create the same function.
WebApi allows to create services that can be exposed over HTTP rather than through a formal service such as WCF or SOAP. Another difference is in the way how WebApi uses Http protocol and makes it truly First class Http citizen.
still the above answer is not clear to me and i think this is not the reason for which people mixed ASP.Net MVC and web-api in same project.
so anyone mind to discuss the actual reason and advantages with example scenario.
thanks
Each have a purpose. Most of the time it's usually caused by legacy code. I know we included documentation which used MVC, but we're fully webapi.
FYI, was MS's auto documentation for WebApi ironically.
Advantage of using WebAPI as ProjectType over InterNet Application in asp.Net MVC?
Is any other use of WebAPI and why it's introduce in MVC4?
To name a few :
ASP.NET web api can be selfhosted outside IIS
ASP.NET web api is not specifically geared towards browsers...
ASP.NET Web api makes making a (level 2/3) RESTful webservice easier
I think that the biggest advantage WebAPI has over other solutions is the built in support for different formats such as XML , JSON, and the relative ease when adding your custom formats. Another advantage worth mentioning is the ability to support extensive OData without coding as much (can be as simple as returning IQueryable), and the support of objects.
That said, WebAPI still have scores of issues that need to be resolved, I keep getting questions from developers that find WebAPI can't resolve their methods, parameters that always result with NULL etc... so I wouldn't swear by it yet, we are all hoping to see a better version sooner rather than later.
I am wanting to build a Restful API using WCF however I am struggling to make a decision on how to accomplish this.
The WCF Rest Starter Kit was developed for .Net 3.5 and has not progressed past Preview 2. Although it can be used within the current .NET Framework and within Visual Studio 2010 it seems from my research to be dead in the water and superseded by the new WCF Web API which is currently in Preview 5.
On the other hand the WCF Web API is only at preview stage and should not really be used in a production application as many things could possibly change before its release. There is also no indication if its nearing completion and if it’s going to be in the next .NET Framework release and when that is intended to be.
I find myself between rock and a hard place and look to the wider community to provide me with some guidance on this if at all possible.
You should regard this tweet from Glenn Block.
Using ASP.NET MVC for building a Restful API should be straight forward and easy way to do it.
However I've used WCF Web Api with WCF Rest Contrib in production without any problems.
See
Creating REST API with ASP.NET MVC that can speak both JSON and Plain Xml
RESTful Services With ASP.NET MVC
ASP.NET MVC – Create easy REST API with JSON and XML
Maybe OpenRasta is what you are looking for?
See also
RESTful framework alternatives to WCF
I depends on your application. If its a Website (also has views) that offers the REST API using ASP.NET MVC would be less technology, less effort, less know-how etc.
If its JUST an REST API choose what you like more from development style: ASP.NET MVC or WCF Web API