I have already a MVC-webapplication, I wounder should I create a new WCF Service Application or should I insert a service in same webapp under the folder "Model"?
What is the best solution?
If the WCF service is exposing models from your MVC project, I would stick it it the same project. If it has logic pertained to code outside the MVC solution, I would create a separate application.
Related
I am working in an MVC web application. This application also use WCF service and Entity-framework.
In solution explorer I have two projects 1. MVC 2. WCF Service.
I am little bit confuse how should I use entities in MVC and WCF service.
For instance I have created Employee.cs class in Model folder in MVC.
And in controller I call a method of Get Employee() of WCF service which returns employee class type.
In WCF service how I will return as employee type because I added that class in Model folder of MVC project which is not accessible to MY WCF service project.
So in this case how I should use that entity in such way that it can be accessible to MVC as well to my WCF service.
Please let me know you need more clarification..
To share the same classes between the projects,create another class library and and the shared code in there.
Then reference the class library from both projects.
I have a ASP .NET MVC4 application using Entity framework CodeFirst and I want to expose its data with WCF data services. I don't know where and how to begin.
Could you give me ways to follow ?
My final goal is to deploy this service on Windows Azure PaaS.
Create a new Web Application project within your solution and add a new WCF DataServices item.
This WCF DataSercices should reference the same business layer as the one you might use within your controllers/model builders in your ASP .Net MVC4 application.
Then have a look here to learn about how to deploy on Azure.
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 have used WCF in the past with my Webforms so my solution was
MyWebformApp = WCF(Model+business) + Web Forms
So when I want to work with the MVC for presentation arch. How do u use WCF with ASP.net MVC ?
Are your data contracts a part of the model ? How do you register the datacontracts as properties?
Roughly here are a few steps:
Create a proxy of the service using svcutil.exe and include it in your application
Create an interface which will abstract all the necessary methods you need to call from the application (IRepository)
Implement this repository and call your WCF service (work with the generated client)
Inject the repository into the controller constructor
In the meantime think about the view models you would set and the mapping between the objects coming from the web service and those view models.
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.