I am building a silverlight application using MVVM pattern but I don't understand what I am missing here...
ViewsProject (Silverlight Application) contains user controls and page. References ViewModelsProject.
ViewModelsProject (Silverlight class library) contains backend code of views. Also the business logic will reside in here. It will reference Models project.
ModelsProject (Windows class library) contains: Ado.net entity model of a local database and a WCF RIA DomainService built on the entity model. It's purpose is to get data from the local database and the entities are exposed via domain service.
Web project: Contains xap of ViewsProject.
Have I done everything correct so far? If yes then please help me understand:
How do I call the methods of the
domain service in the ViewsModel
project? If I reference the
ModelsProject, I get the error that
only silverlight projects can be
added.
If I change ModelsProject to a
silverlight class library project
then I can't add the entity model of
my database.
For client projects to use WCF RIA Service you need to set WCF RIA Services Link in project property.
As for modularity and separation in project architecture when using WCF RIA Services,
you can use WCF RIA Class libraries.
There isn't much sense in separating your views from your viewmodels IMHO. I've seen this approach used before but the view model (in my mind at least) represents a more 'view appropriate' abstraction of the data than the domain model can offer. The ViewModel provides a layer of indirection to allow the presentation to change without the model doing the same but it's little more than a sort of Adapter/Controller hybrid and lives alongside the view.
To answer your question though...
Typically, you'll have your SL project call your domain service (a web service usually) via commanding from your view to the viewmodel. The viewmodel command will then directly or indirectly make the web service call. This web service does not need to be a SL class library since it sits on the web server away from your client.
I get the feeling your thinking in terms of a desktop app here. Remember that the SL project runs client side and your data is not there. To wire all this up your gonna need some remote service to get the data from. A regular library reference is no good since the data is not on the client.
HTH, Stimul8d
I worked out the answer.
Change ViewModelsProject (Silverlight class library) to Silverlight Application type.
Check Enable Ria services during creation of the project.
In the view model class, add using ModelsProject.
Compile the ViewModelsProject.
All of the methods of the WCF Ria service will then appear in the code.
Related
I am hosting a WCF service on a server, and I want to consume the service from my WPF application. My WPF application is written in the MVVM design pattern in two assemblies, one containing the view (xaml), and another containing the models and viewmodels. This works great on its own, but I'm having trouble figuring out how to make the view model consume the service. I tried making both the view assembly and the model/viewmodel assembly reference the service, but that didn't work. The code fails when I try to create a new instance of the client proxy class:
WCFServiceClient = new WCFServiceClient(new InstanceContext(this));
in the viewmodel. The exception thrown says:
Could not find default endpoint that references contract 'WCFService.IWCFService' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this contract could be found in the client element.
I know my WCF works because I have other client applications in winforms that are accessing it properly. Any idea on how this should be done?
I am new to WPF and Entity Framework. I am planning to follow MVVM pattern in a WPF client application and Entity Framework for model. For security reasons I don't want to include the entity framework reference in the client application. I have the following query on this front.
In the above case which is the best way to communicate between viewmodel and model?
Well if you really want to separate the application layers that hard, you could create a WCF Service, which loads the entities from the data source and passes it to the client.
You can find some information on creating a WCF Service here. For information about consuming such services you should have a look here. But you will find many articles in the WWW.
I've made a service for my silverlight 4 database (SQL) affairs (VS2010, C# ASP.NET web app), now I'm writing my SQL functions in this service, how can I use this functions? I've read some articles about deploying services but I think my case should not be much complicated, I have a big ASP.net web app with several web pages (I have a server running on winserver2008), it works great, also I have a SL app, what kind of files should I upload for using service? do I need an asmx? how can I create it? should I change anything in web.config?
what is the easiest way to use my service for communicating between SQL and SL? thanks
WCF RIA Services is the way to go. You do not want to bother with old-school ASMX web-services.
You will use an EF model and a DomainContext on the server to handle all database access via CRUD methods (Create, Read, Update & Delete).
On the client you will use the generated Domain Service client to access data.
Notes from my previous RIA post:
My suggestion is to always create RIA Service libraries instead of adding directly to a Silverlight application. Then you can link the Client-side library to any number of Silverlight applications, then link the .Web part of the RIA library to your website to provide the WCF service. Again the key is to migrate the config settings.
It will probably make a lot more sense if you create a new RIA services library project, add your EDM etc, then link the halves to a separate Silverlight app and your new ASP.net website.
Step-by-step:
Create RIA Services Library project by selecting Add New Project. Select Silverlight on the left. Select WCF RIA Services Class Library on the right. I will assume it is called the default name RIAServicesLibrary1 for this example. It will create a Silverlight client library called RIAServicesLibrary1 and a standard .Net library called RIAServicesLibrary1.Web for use by the Web server.
Add your EDMX to the RiaServices.web project. Select Add new item. Select Data on the left. Select ADO.Net Entity Data Model on the right. I will assume it is called the default Model1.edmx for this example. Connect it to your database tables etc.
Build your project so that the next step will find your data model.
Create a Domain Service referencing your EDMX models in your RiaServices.web project. Select Add new item. Select Web on the left. Select Domain Service Class on the right. I will assume it is called DomainService1.cs for this example. Choose your data items from the Add New Domain Service Class popup window by ticking the checkboxes. A set of RIA services objects and methods will be created for each item you select.
Add a reference to the client Ria services library project (RIAServicesLibrary1) to your Silverlight application.
Add a reference to the web RIA services library project (RIAServicesLibrary1.Web) to your hosting web application (e.g. you ASP.Net website).
Copy/merge the various sections in the RIAServicesLibrary1.Web/app.config file into your <webapplication>/web.config file. This will include any connection strings and the module sections.
Build the project again so that the Data Source window will see your new Domain Context data sources.
Use the RIAServicesLibrary1 client object (called DomainService1 in this example) directly from your Silverlight code like this:
DomainService1 client = new DomainService1();
or use the Data Sources window to drag/drop a new grid etc onto a page.
If the Data Sources window is not visible select the "Data" menu then the "Show Data Sources" option.
For more information try this Microsoft link: Using WCF RIA Services
I am going to develop the 3 tier application using Silverlight + WCF + ORM
Now my question is if I use ORM at database layer then how can I expose the classes at Presentation, Business layer to do Client-Side validation ?
If you used WCF RIA services instead of plain Silverlight WCF, you can attribute the properties of your data objects (in the associated metadata classes RIA creates for you).
This allows you to add basic validation rules, or even custom ones, that runs on both the server and client.
Using WCF RIA Services via a library is the preferred way to organise projects so try this link:
Walkthrough: Creating a RIA Services Class Library
Also:
Using WCF RIA Services
Creating Rich Business Applications using Silverlight 4 and WCF RIA Services
Various Channel 9 Videos
Is is generally a bad idea to expose your business entities directly to the frontend. Not only is what fits your backend layer rarely a good fit for your frontend but you also run the risk of exposing security critical information to the client - which should never be trusted.
An approach that generally worked well for us is developing the Silverlight Frontend using the MVVM pattern and have your WCF Service Layer return DTOs that can be more or less directly mapped to the data requirements of a ViewModel. This also satifies one of the most important rules when developing intranet/internet client server applications and that is to keep roundtrips to a mimimum because a DTO tailored to the needs of a particular viewmodel can include all the relevant information at once.
Before reading, please know I've read all the other posts about the differences between vanilla WCF, WCF Data Services and RIA Services. My question is specifically about why RIA Services is being considered as a special kind of data source specifically for Silverlight when it seems to make more sense to just have it do one job: serve as a business logic layer behind a REST interface.
It looks like with the release of VS2010, RIA Services has solidified its stance as a business logic layer that sits behind a REST data access service - this seems to be confirmed by the new "Expose OData Endpoint" option on the Domain Service Class template in Visual Studio, which as far as I can tell essentially does for your RIA Service exactly what WCFDS does for an arbitrary data source (you could do this before, I believe, but the addition of this checkbox makes it clear that a RIA Service can be viewed as a layer containing business logic used to enhance a REST data endpoint and/or constraint it to a given set of queries, and not necessarily an endpoint in and of itself).
So, if I've got a RIA service with business logic, exposed via OData, I can add a reference to the OData service from a WCF client app. On the client, I get a DataServiceContext derivative that lets me do unit-of-work style work on the client. I can do the same thing from a Silverlight app and get what appears to be the same thing - a DataServiceContext derivative.
If I instead use a "RIA Service Link" in my Silverlight app to directly tie the app to the RIA service instead of adding a service reference, I get code generated by Visual Studio that appears to support pretty much the same patterns of work, but using a different style of API.
That being the case:
What are the advantages of a "RIA Services link," where a Silverlight app is tied directly to a RIA Service, as opposed to just adding a service ref to an OData endpoint that can be consumed by any kind of client without incurring tight coupling? I'm told that the magic of RIA is in the code generation, so I guess I'm trying to understand how the RIA code generation differs so much from "add service reference" code generation.
If there are advantages, why are these advantages made available specifically to Silverlight and not WCF client apps? Selling RIA services purely as a layer behind an OData endpoint seems like it would help standardize and push OData even further in terms of becoming a universal type of endpoint for any sort of client – “consume from ASP, consume from Silverlight, consume from WCF… you get virtually the same experience and it’s a great one.” Instead, we have Silverlight tied directly to RIA with a special set of functionality, and all other clients using the open protocol.
RIA services is not intended as "Domain logic behind oData" to the contrary and quite the opposite. The intention of RIA services is to abstract away the mechanics of web based data access to enable Rapid Application Development in Silverlight. Think of RIA
Services as to WCF as VB is to C++.
The key benefits of RIA Services are:
Transparent Data Access - there's no fiddling with svc files etc. You create an entity framework model, wrap it in a domain service and you're done. More importantly changes are propagated automagically. The developer doesn't have recreate the Service reference every time the model or a query changes, code gen does it for you.
Authentication framework out the box - It's there when you create a business app, it's a template in VS, a way to integrate with existing ASP.NET auth without having to do any heavy lifting.
Data Source Templates and Validation = Probably one of the most overlooked features but yet one of the most important. Have you opened the "data sources" window? RIA services creates User configurable DataContext bound Master/detail controls that support server side validation annotations. A functional data bound app is a drag and drop away. Consider the value of that to someone who is more Design/Blend focused.
In short RIA services is built for a developer to be able to go from an edmx data model to a secure functional Silverlight up in a matter of hours. It's awesome stuff when used in context.
As a note, I've done quite a bit of research on RIA Services and Data Services and they fulfill different needs. We use RIA Services for all our desktop replacement apps, but we use Data Services for SaaS.
I don't think you're far off with the long term intention of RIA services though. I think we'll see oData and RIA services get a lot closer in future versions.
The OData endpoint exposed by WCF RIA Services does not support query operations and returns data as-is. That means no benefit from IQueryable, sorting, parameters, etc. It will simply expose your methods; end of story. There is rumor that this will change in the next release however. However, what RIA Services provides from the standpoint of IQueryable on service calls, automatic propagation of business rules from the middle tier to the UI, and INotifyDataErrorInfo for flowing validation errors to the Silverlight client is outstanding should you choose to leverage them.