Is it possible to host in the same appDomain two different projects of WCF service and MVC application?
For example, I need to use some pulic static class from MVC application by my WCF service. But they are in different projects, so this class for them is in different appDomains.
It is quite common to host WCF services within an ASP.NET application (MVC or WebForms). From a coding perspective, the only thing you may need to configure is ASP.NET compatibility mode, if the code WCF is calling requires access to the current HTTP context.
Create your WCF service contracts, and implementations of those contracts, configure your services, bindings, and behaviors in the web.config, as you normally would. Here is another example, which you could create in virtually any ASP.NET application.
Related
I've desgined my ASP.NET MVC application using the Domain Driven Design, and I got the following projects:
MyApp.Core - the app core, contains the domain models etc.
MyApp.Infrastructure - the app main infrastrucutre, contains implementation for the domain model storing (repos etc.) using EF.
MyApp.Web.Core - domain models, services declaration (interfaces) and such only for web (e.g. IFormAuthenticationTicketSupplier, IOAuthAuthenticationProvider etc.)
MyApp.Web.Infrastructure - web implementation
MyApp.Web.UI - ASP.NET MVC standard application.
This application should be used by enterprise with multiple servers, etc. Currently, the application calls a service in the infrastructure layer at the controllers, which uses Repositories and EF. I can connect to the DB server using the connection string.
When digging about this topic at Google, I've read that some approches taken when creating an enterprise application are create an Application server and Web server. In the application server - storing a WCF service, and in the web server just calling it.
I'd like to know if I should do so (if creating a WCF service is the right and required approch when dealing with enterprises):
- Why should someone not just use the Services in the controllers and instead use an API?
- In case I'm using an API, it won't slow down the response? since even if the computers are on the same network, I still open an HTTP request.
- If I should use WCF, or ASP.NET WebAPI?
Thanks for any feedback and help!
First, regarding your projects, is there a need to split up MyApp.Web.Core, MyApp.Web.Infrastructure and MyApp.Web.UI? Sure they may be separate responsibilities, but sometimes dependency hygiene trumps encapsulation. You can always leave them in separate folders and namespaces. I wouldn't extract something into a separate project unless I needed to reference that as a library from elsewhere.
As far as the application service, that also depends on your needs. If the only place that would call that application service is the ASP.NET MVC app, then there isn't much of a need to extract an application service. There are some benefits however. One is that you don't have to worry about all of the dependencies required for a service - you just references it via Url. And of course you have the ability to call the service from places other than the controller, although the MVC controller can act as a pure HTTP service as well. You also have the ability to deploy updates to a specific service without releasing the MVC app. But you do have the burden of maintaining a separate service. If you do go that route, go with the WebAPI, WCF is just too much abstraction.
I am working on a web service which is going to have both a native WPF client as well as a Javascript based web interface.
While I was working on the service and WPF client, the WCF service has been an IIS hosted WCF service project of its own, and has been working fine. Now that I'm starting to work in earnest on the web interface, I am wondering if keeping the WCF service separate is a good choice.
Reading around on the subject, there seem to be lots of options regarding this; for example, I could:
Keep the two projects separate
Create the asp.net MVC website and add an Ajax-enabled WCF service to the project
Create the asp.net MVC website and add a WCF service to the project
Create a WCF service library project and have that hosted in the MVC application (not entirely sure about this, but it seems possible)
And I have a feeling there's probably more.
What do you suggest I should do? My goals are:
Accessing the service from the WCF client using a service reference like I have done so far
Accessing the service from Javascript on the web interface
Accessing the service using port 80 from Javascript and the WCF client (to avoid firewall issues)
Having website and service under the same domain
Being able to run the thing using shared hosting (Gearhost), without multiple IIS virtual directories/application starting points.
Recommended: I would suggest keeping the projects as separate as possible. It allows more flexibility in how everything can be hosted if your app takes off and you need to separate to different servers/app pools/etc. Also, separation of concerns is one of the Service Oriented Architecture (SOA) tenets. This will force you to code your service in a way that is "generic" enough that might promote re-useability down the line. Forgive me if this is below you but I need to say it: In visual studio you can create an empty solution and add in each of your individual projects so you are working all within one instances of visual studio.
Then in your IIS instance you would have something like this:
/ = root app
/servicelayer/ = virtual application
But... you have a goal of "Being able to run the thing using shared hosting (Gearhost), without multiple IIS virtual directories/application starting points." You cannot host separate asp.net applications within a default IIS directory without marking them as virtual applications. This means you can not just paste the servicelayer application folder into your root application folder.
Because of that requirement then the only option you have is to add your service code into your asp.net mvc application. I'd create a folder called "/services/" that houses all your endpoints so that it's slightly separated. Then add an Ajax-enabled WCF service to that folder.
In the end I decided to create three projects: the service interface, a dll holding service and data contracts, the service library itself, which references the interface, and the website, an MVC application which hosts the created service library. The MVC code interfaces with the service as if it was hosted on a different system, using a client proxy (which in this case connects to itself, funnily enough). This should allow me to host the whole thing in a single virtual directory while still providing for not-too-painful decoupling down the line if need be. To keep things tidier, I am creating the service proxy manually in code by referencing the interface dll and NOT using the "add service reference" function.
I am developing an ASP.NET web application (C#.NET 4) in a scenario where I need to consume WCF SOAP Services (VB.NET 4) provided by another development team as the model.
Services are hosted on IIS using AppFabric. The WCF implementation is created to support the following scenario:
A shared data service layer that is language/platform independent. A requirement is also that services should provide a black-box when front-end development is outsourced to external developers. WCF SOAP services are used to provide the common web based API. Consumers of the services are both web applications and desktop software that are internal and external.
My question is about my current web application architecture. The application is developed using ASP.NET MVC 2 and jQuery UI. From what I have read this far it seems that using WCF SOAP Services as the model is ok. My plan is also to use ViewModels and AutoMapper based on this post:
Using SOAP web service object as a model in ASP.NET MVC 2
What are the pitfalls if any?
How should I develop the communication with services?
Are there overheads in term of communication with this kind of architecture?
Any Best Practices?
(Re-engineering the service layer to OData is not an option at this stage)
If you think about your web services as a "remote database" you can just follow the same practices that you would when developing an MVC application against a database. But be prepared for far more disconnection problems that you would otherwise.
I would suggest you create your model to wrap the calls to the web services and provide any error handling logic that you will need (which will be probably a lot if the web services will be remote.) Remember that network connectivity on a WAN is not guaranteed and hiccups are not unusual.
I'm a little new to DI containers like StructureMap and I've been using it for a short time with asp.net mvc applications. Now I'm splitting my architecture that will have a WCF service layer and a sort of consumers like ASP.NET MVC app, Silverlight App, And Winfors/WPF App. When using SM with asp.net mvc I've been initializing the IOC by the app startup of the asp.net mvc, now, using for many project I can't think a good place where the IOC config should be located.
I want to make DI in the services layer too(injecting Repositories).
In this scenario, where I do load my IOC config and how I'll use across the projects(like the controller factory is needed only in the asp.net mvc app)?
You create and configure a container per application.
If you have an ASP.NET MVC site, you create and configure a container instance in Global.asax.
In a WCF service you can write a custom ServiceHostFactory that spins up a custom ServiceHost that again attaches an appropriate IInstanceProvider that uses a container instance to wire up the WCF service. That sounds complicated, and it definitely is more complicated than it ought to be. I have previously touched on this subject in a completely different context, but this blog post should give you some hints - particularly if you keep in mind that delegates are anonymous interfaces.
A Guide to Designing and Building RESTful Web Services with WCF 3.5, this article explains the foundations of REST and how it relates to WCF. MVC uses REST as the architectural model. I am guessing one can use the .NET MVC to create web applications that have both a front end and an API point, but I am not sure if the safe way of building the API is to build it with WCF and then use it in the MVC as a controller.
Please comment if the question is not clear, I will add or modify the text.
Theres actually a third option, ADO.NET Data Servies. Anyway, here how I see them.
MVC REST: Gives you full control over how to expose your data, you have to write all the code to get it up an running tho, e.g. serialization, deserialization, all the CRUD methods etc etc. Worht metioning that this being an MVC site means you are limited to exposing your service via IIS over HTTP(S)
WCF REST: More automation than MVC, a much more solid frameowkr than MVC REST, i.e. caching, security, error handling etc (basically all the stff you'd have to write yourself using plain MVC). Being WCF, you can host this in a variety of ways (e.g WS-, TCP) etc.
ADO.NET DATA SERVICES: The quickest way to get up an running with everthing ready to use, all you need todo is configure the global.asax, however you have to use an Entity Data Model, which you many not want to.
Personally, I would use either ADO.NET DATA SERVICES or WCF REST to build an API, consue that API in MVC site and then expose that API either directly, or by passing it through another layer.
ASP.NET MVC can serve as a REST endpoint for light services work, so I guess the answer to your question depends on how you define "safe."
Clearly WCF is designed specifically for creating REST endpoints, with all of the security implications that are implied thereof, whereas ASP.NET MVC is designed to create REST endpoints which can be used by ASP.NET MVC itself.
The following article shows how to create a web service using an ASP.NET MVC controller:
Create REST API using ASP.NET MVC that speaks both Json and plain Xml
http://msmvps.com/blogs/omar/archive/2008/10/03/create-rest-api-using-asp-net-mvc-that-speaks-both-json-and-plain-xml.aspx
See also the following article from Phil Haack, which discusses an SDK the WCF team put together for users of ASP.NET MVC:
Rest For ASP.NET MVC SDK and Sample
http://haacked.com/archive/2009/08/17/rest-for-mvc.aspx
They are two different sets of technologies, only related by being built on .net
MVC is used to create websites and provides a model where URLs are routed to controllers and controllers deliver views to the user as the user interface.
WCF is a set of libraries in .net that are used to abstract the type of service (is it hosted in a windows service, as a webservice in IIS etc.) as well as the protocol (HTTP, TCP, MSMQ etc.) from the client and server which are communicating.
An MVC website may use WCF to connect to a web service, but that is just one of many options.