I am working on an MVC4 existing application. The application is related to web services.
There are 4 projects in the application:
DataLayer - Contains edmx files
Web - Contains:
Models, Views and Controllers
Service References naming ProfileService and EditorService
Services - Contains:
Data Models (sending/receiving of data with database)
IProfileService and IEditorService
ProfileService.svc and EditorService.svc
Services.Client - Contains ProfileService.cs and EditorService.cs
My Questions:
Can someone help me understand the relationship between these
projects?
In Service.Client, ProfileService.cs and EditorService.cs are
auto-generated files. Can I know how these class files are created?
What is the difference between Services and Services.Client?
Below is the upload of ProfileService.cs file (auto generated)
Relationships (as in a typical architecture): Web accesses services, Services accesses DataLayer. Services.Client might be a library for projects that want to access the Services directly - and as such could also be used by the Web application.
Typically, these files are created when adding a service reference to a project. You can also use svcutil.exe to generate them. If there are no service references in the project, the probability is high that the latter approach was used.
Services are installed on a server and offer the services to clients. Service.Client provides the infrastructure to access the services. These are used by a client to the server. Note that in this case the term "client" refers to any software accessing the services and does not mean that it has to run on a client computer. The web application that is hosted on the server is also a client of the services.
Related
I am developing a blazor webassembly program with a web api backend. The backend uses a WCF service reference.
How can i share the types/models generated by the WCF service reference with the webassembly program?
You could try to create the client proxy in a different project. I don't remember any options in VS, you may have to use the command line tool.
But I wouldn't.
The generated code usually isn't the prettiest, with lots of metadata, dependencies and properties you don't need or want in your SPA.
So consider writing a layer of DTO classes in a shared project and use AutoMapper to convert the data.
DTOs are Data Transfer Objects, the shared code between Client and Server. In your Client you can use them as Models and/or ViewModels.
We are starting a new project and trying to implement some concepts from Domain driven design. We are planning to have following layers:
Web Interface (WebAPI)
Application Services (library)
Domain Services (library)
Data Access Services (Library)
We are thinking about merging Web interface and Application service together. So, our webAPI will be talking to repositories, domain model and domain services.
Is this fine or should we have separate project form application services and WebAPI should only communicate with Application services?
Thanks
HTTP should be seen as one of potentially many access ports to reach your application services. If you could be entirely sure that you will never have to speak to your application through another communication channel than HTTP then I'd say it's perfectly not to have a seperate application layer.
However, I'd also say that it's very hard to predict how application needs will evolve and since adding an additionnal layer of indirection to segregate the application layer right away shouldn't be very costly (it's just delegation) that's what I'd do.
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 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.
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.