I'd like to be able to get the url that the app is hosted on. There will be various ways that clients will access the service layer, through an asp.net mvc app, wcf (hosted on the mvc app).
My service layer is in a dll. Is there any way that I can get the url pointing to a specific action when a remote client uses either entry points to the system?
It is possible - but not a good thing to do. You are binding the business layer to an implementation detail which is higher layers and business layer should have no knowledge of.
You can use various OperationContext.Current properties (depending on your binding) to get to the address.
For example, OperationContext.Current.IncomingMessageHeaders can be used for HTTP or OperationContext.Current.Host.BaseAddresses if there are base addresses. You just need to evaluate which one provides the address you are looking for depending on your configuration.
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 three core applications that have their own business functions (networks, active directory and helpdesk). Each are running ASP.NET v2 or v3 and have their own respective databases. However, the application functions have merged a bit so models were recreated in each application and app logic along with it. So now I have some difficult to maintain code. So here is my question:
Is porting my models and repositories over to WCF a reasonable choice for this type of architecture?
Is using a service stack such as serialized json calls a better choice? I'd imagine this would be faster than setting up a central wcf app.
I'm not too familiar with communication between asp.net mvc web apps so please point me in the right direction.
I would recommend developing a service layer per the design pattern described by Fowler. This service layer encapsulates the various domain models and repositories and handles interactions between different domains/models. This will be an assembly and not a WCF or any other type of web service. If you require a WCF web service then it will be a very thin layer which basically has a contract that mimics the service layer and only purpose is to provide a web service interface or API.
There are a couple of ways an MVC application can interact with your service layer. If you are creating view models in your Controllers then it can access the service layer assembly directly. There is added overhead to calling it through a web service that is most likely not necessary in this case. Using this approach the service layer is pretty much your Model in the MVC trio.
The other way to access the service layer is from the Views/client using AJAX for rich clients. In this case you would use MVC to put a REST API on top of your service layer so that you can make AJAX POST's, using something like JQuery, directly to the web service to update and retrieve data for the web page.
Note with this architecture you can use a combination of both approaches. You may access the service layer directly from the Controller to render some initial pages and then use the web service REST interface for AJAX calls during user interaction.
I'm looking at putting together a REST based system which still has a standard browser style access. My desire is to have both of these on the same machine, but what are my options?
Use IIS to host both the web-site and the REST service (different URIs, e.g. http://mysite.com/ and http://mysite.com/api
Use IIS and some magic I don't yet know to have two domains mapped to the same machine but different services (e.g. http://www.mysite.com and http://api.mysite.com
Combine the two technologies into a single service (that perhaps uses routing tables to direct the requests to MVC or WCF where appropriate).
My preference would be the third option, this would allow me to have a single code-base and single repository accessing. The WCF page on codeplex mentions in its release notes, "not tested with MVC3" - is this suggesting that this is a possible approach?
I'm not keen on using MVC for the REST implementation as it is intended that the majority of interaction with my site goes via API, so I want that as the focus.
I've ported the contact manager to use MVC 3. It definiately works though we've not done exhaustive testing. The one thing in general to cognizant of with regards to web api is that both MVC Routes and Service Route are greedy. If your default route is first then MVC will try to grab your HTTP Service requests. One thing you will want to do is put your Service Route first before your MVC routes. If you run into additional issues, you may need to use custom routing constraints.
In http://webapicontrib.codeplex.com there is a sample that works with MVC 3. It is in the Samples/experimental folder. However, it was built with a custom version of WCF Web API. I don't believe it needs to be though. I've been meaning to get the author of the sample to switch it over.
I want to send an email confirmation from my service layer (class library). This can be triggered from an asp.net mvc controller or a wcf service.
How do I build the Url from the service layer?
The service layer shouldn't have knowledge of how urls are constructed in your web application, especially because those rules can easily change. Also this makes your service layer tightly coupled to the web layer and less reusable. What if tomorrow you wanted to reuse this service layer in a desktop application?
IMHO that's an information that should be passed from the controller to the service layer.
I'm wondering if it's possible to service up WCF services via MVC. I've seen a few posts about this as it relates to RESTful services, but I'm not looking to create a RESTful service.
I've also seen this topic covered as far as serving up .svc files from MVC, but I'm not looking for that either.
Basically, I'm just looking to expose my WCF services via MVC, instead of a typical Wep App type structure with svc files.
so instead of having ttp://localhost/MyService.svc, I would just have ttp://localhost/MyService and that would go to a controller that would return the data.
Is it possible to have a "servicehost" controller? I would assume that the biggest obstacle to this would be that IIS handles the service a certain way based on the .svc extension - would some kind of custom handler have to be set up for something like this?
Any thoughts?
You can do this without MVC (or, it seems, with it too)
http://geekswithblogs.net/michelotti/archive/2010/08/21/restful-wcf-services-with-no-svc-file-and-no-config.aspx
http://geekswithblogs.net/michelotti/archive/2010/09/22/wcf-rest-services-inside-mvc-projects.aspx