What is the best experience of combining wcf services in an asp.NET application?
Should I add wcf services files to the asp.NET project?
Should I create a separate project for the wcf services and refer somehow to them in the asp.NET application?
I presume you have an ASP.NET application that also hosts a few WCF services that can be accessed from the client. There is nothing wrong with this and it works perfectly well.
The three things you should consider doing are:
separate the interfaces for the WCF services into their own assembly
keep the data objects that you use in yet another assembly
separate the implementation of the interfaces into their own assembly
This may seem like overkill, and it's not always necessary to do it this way, but i would do at least steps 1 & 2. Keeping the data objects and contracts (interfaces) in their own separate assemblies is important as it helps when sharing (referencing) the data objects from different projects (i.e. if you have a Silverlight or Windows Forms/WPF client that can consume those assemblies).
Separating out the implementation (step 3) is good, but not the most important thing to do. If you do follow this step, you can still publish the WCF endpoints through your ASP.NET application.
Related
I have a web site and would like to expose certain functionalities using WCF.
Before deciding which type of WCF project I need to use I wanted to compare the differences between WCF Class library and WCF application. I know this question has been asked many times and answered many times and the answers are usually about different hosting options each one offers but I wanted to try and see the differences, so this is what I tried:
Step 1 - In a same solution, I have created a WCF Service library project and created Client console app project, set the console app as a startup project, referenced the service library project from the client project
and in the client console app I could instantiate the service and can consume the service methods. I didn't even add a service reference to the client project.
Step 2 - In a same solution, I have created a WCF Service application project and created Client console app project, set the console app as a startup project, referenced the service application project from the client project
and in the client console app I could instantiate the service and can consume the service methods. I didn't even add a service reference to the client project.
On both steps after compiling the solutions I was able to copy the client app's exe and the service dll's to a different location and still be able to run the clients.
Based on this little excercie I am confused about the hosting part. It seems wether I use WCF Class library or WCF application type I get the same result.
This is just like using multiple projects in a solution, you reference one from another and use the methods, there must be something I am missing which highlights the differences between the two and highlights the benefits of using WCF, also in the past I remember I had to add a service reference to the clients apps in order to consume the service, why is this not the case here?
Thanks
1) Running a wcf service application allows you to provide communication into a single application, where you have a single instance of a thing you want to provide access to. Maybe this is a game, or a chat room without an external state engine or datastore. This is useful for providing diagnostic information about an application you might have written for example. I used this to provide external control for an industrial robot that I wanted to provide remote control access for.
That is to say, that you write an application, it has a function. You want to expose part of that functionality to remote applications. You do this by adding a WCF endpoint to your existing application, so your application itself is controlling the WCF hosting elements, lifecycle of the endpoint etc.
2) Running a WCF Service is for when you've got an external data store, or your service is stateless. A translation service, lookup service and web page requests fall into this category.
With a service class, you're saying here is this service, this thing that provides a function. It isn't tied to the lifecycle of another application or process and is typically hosted by IIS. IIS manages when the class is loaded and run based on the requests that come into it. These services have no internal persistence and rely on an external datastore, or are, by nature, stateless (think of a postcode lookup, or a calculator service)
It sounds like you're actually adding the projects as references, rather than connecting to them as services. That is to say, that the consuming application is actually loading the service as an assembly (in the same application/ memory space) rather than as a separate application/ service that your application then uses WCF to communicate with.
The WCF Service Application template can be used to create WCF services with a hosting website created within the project
The WCF Service Library template can be used to create WCF services that are hosted by the WCF Service Host, and these can be tested using the WCF service Test Client.
the biggest advantage of using a standalone library (apart from decoupling the logic) is that you can easily migrate your service, i.e. host it in another application or another type of application. E.g., let's say you're hosting your service using IIS - you can easily move your service to a standalone application, etc.
I am in the initial stages of working on the design for an application. There will be the following:
Web interface
Web Service
Leveraging other pre-existing web service
I am new to windows services and SOA especially in the context of Visual Studio.
My question is, how would I set this solution up in Visual Studio? For example, would I
Put the web UI and service call in the same project, and put my service in a separate project and then put all of the above in a solution?
What is the best way to begin structuring my solution so that it can be traceable and tested?
I like to structure my WCF solutions like this:
Contracts (class library)
Contains all the service, operations, fault, and data contracts. Can be shared between server and client in a pure .NET-to-.NET scenario
Service implementation (class library)
Contains the code to implement the services, and any support/helper methods needed to achieve this. Nothing else.
Service host(s) (optional - can be Winforms, Console App, NT Service)
Contains service host(s) for debugging/testing, or possibly also for production.
This basically gives me the server-side of things.
On the client side:
Client proxies (class library)
I like to package my client proxies into a separate class library, so that they can be reused by multiple actual client apps. This can be done using svcutil or "Add Service Reference" and manually tweaking the resulting horrible app.config's, or by doing manual implementation of client proxies (when sharing the contracts assembly) using ClientBase<T> or ChannelFactory<T> constructs.
1-n actual clients (any type of app)
Will typically only reference the client proxies assembly, or maybe the contracts assembly, too, if it's being shared. This can be ASP.NET, WPF, Winforms, console app, other services - you name it.
That way; I have a nice and clean layout, I use it consistently over and over again, and I really think this has made my code cleaner and easier to maintain.
This was inspired by Miguel Castro's Extreme WCF screen cast on DotNet Rocks TV with Carl Franklin - highly recommended screen cast !
I am writing an application ( WPF ) where i use the prism framework. I have a client with the shellview.
I have some module's. So that are different projects. Each module is a sepperate project.
The modules are loaded by Unity.
I have the following
Solution
Client
Modules
Client ( app )
Common
Entities
Server
Data
Web
So you can see i have an Data Project under the server folder. There you can find the edmx.
The Web project is empty, the Entities project is also empty.
The Client (app) has a shellview with its bootstrapper.
The client works. Only the data access layer must be integrated.
What is the best solution to do the data access? WCF, something else?
What template do we need to use for the entities. How can we use the service in the modules where al the code (View/ViewModel) is?
Pff, i am looking and read so much.
Found some topics on stackoverflow. But none of the topics start's from the begin.
Hope someone can help me.
I suggest you to generate POCO or STE on .edmx and use the Repository Pattern for database access. Create a Separate WCF Service Project and call these repositories.
Your Prism Solution will have a Proxy Project with Static Class to return Service Object and your Client (Prism) App will call the WCF Services.
May be you can have a look at Calcium SDK (http://calcium.codeplex.com/) which leverages Prism modular app development along with support for WCF services.
If you are familliar with WCF and EntityFramework on the server side then this is the way to go.
In order to reuse the generated proxy classes from services you can keep your service references in a common assembly that you reference from all modules. Something like "Infrastructure" is a good naming convention.
In case one of your modules needs a unique functionality then you put the service reference on that project.
In case of WPF clent: Use entity framework code first and seperate your Model classes in a seperate assembly so you can reuse them in your main client and modules.
In case of silveright client:
If duplicate model classes and namespaces when generating the service proxy is an issue for you you can checkout WCF RIA Services. Always keep in mind that you can link two assemblys a silverlight and a .net one using RIA Link in Visual Studio project file properties. Then any server side code file you chose can be reused on the client. This is possible using the "shared" suffix in your filename (ex: enums.shared.cs) regardless if you are using WCF services or not. You can find out more here and here
Hope this helped.
We have an application in which we have created a service layer with most of the business logic and utility services (logging, exceptions, caching etc). We have to come with a way to expose this service as an API to the UI components. Here are some of our requirements:
We would like to create multiple
components based on the service.
We would like third party developers
to use our service to create their
own components or utilize our data.
For scalability we would like to have
a multiple instances installed on
different boxes. Similarly there
could be more than an instance of the
same UI component.
One way to expose the service layer is to host it under a REST based WCF layer.
The other way is to host the service in model layer of an ASP.Net MVC project. The UI components will be hosted in MVC projects of their own. The Javascript in the views of UI components will directly call the controllers of service project.
WCF is supposed to be very heavyweight option. On the other hand I am not too convinced with the MVC approach as I feel that this is not purpose it is meant for.
Could you please recommend me a way in Microsoft world to expose our service layer.
WCF seems to be the way to go here. Although WCF started out (in my oppinion) as a beast, it got tamed over the years with better HTTP and JSON support and less custom configuration (although still allowing you to modefy basicly every little aspect of your service).
Exposing your current service layer as a REST Service is a breeze and allows your customers/yourself to easily consume it on any device that supports HTTP.
See: http://codebetter.com/glennblock/2010/11/01/wcf-web-apis-http-your-way/
Models are not services. Models are POCOs that hold data.
You can expose your service through a WCF Service, and let your ASP.NET MVC app consume it. If you're always sure that the service will run on the same box as the client app, you can use named pipes for transport -- then the overhead of WCF is minimal, compared to the advantages.
WCF seems to be the direction that Microsoft is headed for this and for good reason. WCF services are the best option here because you mentioned third-party development support. Because these web services are defined by a WSDL, they are cross platform and can be consumed by non .NET applications.
It perfectly seperates your service layer to be consumed by ANY components.
I'm about to start building WCF web service, and i would like to structure solution in such way that is would be:
Easy to develop - i would like so that developers on my team could just get sources, build, and start service, probably best would be to have possibility to start it as console app?
Easy to host this service later in IIS, WAS or windows service.
I was thinking about having this projects:
Shared (for web service interface)
WebService (for actual implementation of web service and svc file)
ConsoleHost (for hosting web service in console app)
Will there be any problems with such approach?
What could be things that i should consider in advance?
Maybe there is better structure?
I would appreciate any insights and links to resources that could help me chose right structure.
p.s. web service itself is simple, but this approach would be reused for more services.
What I tend to do is to place all my interface definitions in one assembly/project, all the service implementations in another assembly project, and the hosting environment, whether it be console, IIS (ie the .svc files) or windows service or whatever, in a separate assembly.
With this information, I say this structure looks fine.
You might also consider creating a separate ServiceModel assembly to store all your custom behavior and WCF. They could then be reused for other projects