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.
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.
I want to do CRUD by web-services(WCF), but i am using boilerplate framework , my question is how to work with web-services(WCF) in boilerplate?? any helpful link or tutorial??
Create a new project in your solution with WCF application, add wcf service in this new project, use entity framework and then write services you need, then in YourProject.Web project add service reference and get the service you need. Create object of the service in your controller and get or post data according to your need. Set multiple startup projects from solution properties and give WcfService-Project and Yorproject.web-Project as start. Now start both projects and use services. That's all.
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.
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 !
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.