i need to understand when these two implementations used . what could be the motive of using one over other , can these be leveraged interchangeably.
Thanks in Advance
Dee
An IHttpHandler is a "do it yourself" solution. You'll be handling everything yourself, and you'll be responsible for things like interoperability.
Using a web service (a WCF web service), you'll get serialization / deserialization, an infrastructure, and an ability for a client to easily consume your service.
For a "service"-type operation, use a web service. If your task doesn't fit that, then consider IHttpHandler.
Related
I have a .net Web API 2 application that I need to use to call an web service (asmx) just to see if the web service is up and running correctly. I am a believer in architecture, so with that in mind I am not sure where to put the call to the web service. I found a post that suggested that I put this in the repository layer. Is this the correct location for that?
I would say its more of a personal preference + project specific; IMO you can place that web service in repository if it acts as a data-store or you could place it in business layer of the service does more of a business related stuffs.
But one thing I would do for sure is to create a wrapper/abstraction over this service before using it in any layer so that:
I can inject this dependency in the layers its being used
Unit testable code - DI and mockable
No changes in the layers where this is being consumed in case there is any change in service- for eg, asmx1 to asmx2 or change in asmx service to wcf or REST etc.
Not sure whether you will be able to find a specific answer to this, this is kinda arguable subject as opinions might differ according to personal preference
I have read through the SimpleInjector documentation a few times. But have a few questions.
Context:
3 tier app (presentation (mvc + api controllers), service (business logic), data (repositories, entities, etc)
Unit of Work is a thin wrapper around EF's DbContext
my DbContext and Unit of Work are registered PerWebRequest, using
RegisterWebApiRequest causes an exception, because the Unit of Work is used
outside of Web API requests.
my MVC and Api controllers registered using RegisterWebApiControllers(GlobalConfiguration.Configuration) and RegisterMvcControllers(Assembly.GetExecutingAssembly())
Each controller has one or more services injected into it.
Each service has one or more repositories injected into it.
A service may also have another service injected into it.
I want the same Unit Of Work/DbContext to exist in all my services/repositories.
Questions:
Because I am using services in my MVC controllers as well as API controllers; does that mean I can not use RegisterWebApiRequest in place of RegisterPerWebRequest?
none of my services, repositories, etc, maintain any state, I would get the same functionality using PerWebRequest as Transient; is there any advantage to using PerWebRequest over Transient?
Please read the following q/a: How to configure simple injector container and lifestylse in a MVC web app with WebAPI, WCF, SignalR and Background Tasks. The answer explains that:
Putting your Web API in the same project as your MVC controllers is a bad idea from an architectural perspective.
But if you want to do this, you can use the WebRequestLifestyle in both type of applications. The WebApiRequestLifestyle is meant as lifestyle that works for Web API for both IIS and self-hosted environments, but since you placed the Web API controllers in the same project, you are clearly only interested in IIS-hosted; in that case the WebRequestLifestyle will do just fine.
Because I am using services in my MVC controllers as well as API controllers; does that mean I can not use RegisterWebApiRequest in place of RegisterPerWebRequest?
Both lifestyles use a different way of caching. The WebRequestLifestyle uses the HttpContext.Current.Items dictionary to store its SimpleInjector.Scope instance, while the WebApiRequestLifestyle uses the CallContext class to store the Scope during the lifetime of a single asynchronous operation.
Just as the WebRequestLifestyle can be used while resolving Web API controllers, you can use the WebApiRequestLifestyle (or the underlying ExecutionContextScopeLifestyle) for MVC controllers as well. But if you want this, you will create your own IDependencyResolver implementation for MVC that will explicitly start and end an ExecutionContextScope. The absense of a Scope stored in the CallContext is the reason resolving MVC controllers fails when registering services using the WebApiRequestLifestyle. But while it's possible to use the WebApiRequestLifestyle in MVC, the otherway around is much easier, since no custom code is required.
none of my services, repositories, etc, maintain any state, I would get the same functionality using PerWebRequest as Transient; is there any advantage to using PerWebRequest over Transient?
If services don't have state, it doesn't matter what lifestyle they have. The only restriction is that they have dependencies that have a lifestyle that is equal to or longer than their own. Violating this restriction is called Captive Dependencies and can cause all kinds of trouble. Because captive dependencies are bad, Simple Injector v3 checks and prevents this for you.
Although you can probably make all objects in your configuration scoped (non-transient), making them transient is usually easier to configure, and might result in better performance (although you will probably never notice the difference in real life).
I'm beginning development of a new Asp.Net MVC app. One of the requirements is to expose our API using a webservice - we're going to use WCF for this. (We have a third party making an iPhone app that will consume this service)
I'm writing the Asp.Net MVC application that will also consume the WPF API.
I'm thinking that because my MVC app will be installed on the same instance of IIS that the WCF app is on, and it will also be part of the same Visual Studio project that I could just call the service methods directly - instead of making calls through the web service.
For example in my controller class I could just do something like
WcfService.SomeClass someServiceClass = new WfcService.SomeClass();
var stuff = someServiceClass.GetSomeStuff()
Is this possible? If so is it wise?
Is this possible?
Yes. You could either import the assembly containing your WCF service contract and implementation into the ASP.NET MVC application and directly call it from there.
If so is it wise?
Yes, you will gain performance this way as you will be short-circuiting the whole serialization/deserialization and network call process.
So if the two are hosted inside the same ASP.NET application you could do it.
Is this possible?
Sure. Darin is right about this.
Is It wise?
That depends ! Your WCF service can be implemented in multiple ways, for example you can (and maybe should) implement concurrency and instance management other that "per call" - which will work only when service is hosted in WCF capable hosting enviroment and called properly. If you start using it this way
WcfService.SomeClass someServiceClass = new WfcService.SomeClass();
var stuff = someServiceClass.GetSomeStuff()
you are giving up on some very good features WCF offers you to improve scalability and performance. Give it a thought, if it the "serialization-deserialization" overhead is worthy of it. It very well can be !
I would appreciate if someone can provide some insight into which one is more beneficial.
RESTful service in WCF can provide the same functionaly as ASP.Net MVC Controller, i.e URLS can be formed appropriately using Controller/Action.
Is there real benefit of using one over the other.
WCF Rest service will provide..
1) Cert Authentication out of the box
2) Logging
3) Message Headers etc
MVC
1) Different Action Results out of the box
If someone has used or debated these two technologies . please let me know
UPDATE:
I went ahead with the MVC Model as it gives me lot of flexibility and I can use the same action to render different views with CustomActionInvoker, which is really cool!!!
-RN
WCF makes your service more manageable and offers more protocol options like TCP, Named Pipes, PerChannel, and MSMQ.
WCF gives you the ability to specify multiple methods of binding to the service through the web.config including restful urls, giving you greater flexibility. In conrast, mvc provides you with the ability to easily construct resful urls and output data via code in much the same way as you do a web application, which is really easy and requires minimal additional knowledge if you already know mvc.
My recommendation would be to go with wcf if the service is really important to the overall solution, likely to be called in a different or many ways or has or is likely to have special security requirements.
On the other hand I would go mvc if this is meant to be a quick and simple isolated solution or perhaps is just providing a different representation of data being output in an existing .net mvc application.
At this point in time, your best option is ASP.NET MVC. It provides cleaner access to the HTTP primitives you need to be able to design RESTful solutions.
The only significant advantages of WCF Rest is the ability to self-host the service and if you want to use ADO.NET Data Services to deliver OData/Atom services, then obviously WCF is your best choice.
I am using .Net 2.0 framework and would like to call a function in Windows service from a web service. Is this possible? And If yes, how much control I will have over the function i.e passing parameters, getting the result back etc. Any ideas would be greatly appreciated :)
Remoting is your best option if you need to pass parameter values.
If you don't need to share objects or anything too complex, ServiceController is probably easier.
You can do it through .NET remoting. If you go that route, it will appear you are calling a method and getting a result, but all your parameters will be serialized over the wire, and the result will be serialized back. Therefore, everything must be made serializable.
How about hosting a WCF service inside of the Windows Service. You can use net.tcp or named pipes to communicate between "your" web service and the one in the Windows Service. You can use the NetDataContractSerializer for serialization with type fidelity.
You could implement a basic http server that maps certain requests to functions. Query-string will be mapped to parameters. Actually not hard and I have done this in the past (as I provided some rudimentary template-based reporting). It wasn't dynamically, but it could be done dynamically. Look at HttpListener for a starting point. You could as well host the asp.net engine in it.
It has it advantages and disadvantages.
Why not package the function in its own DLL then distribute it with the Windows Service and the Web Service separately?
Create service project what export an interface COM or use PIPE to transfer data.
View this Interprocess Communication using Named Pipes in C#