I am uisng Silverlight 3 and ADO.NET Data Services with a cusotm-built Model (separate project) and DAL (separate project)) in place. Within my Silverlight project, I create a [Service Reference] that references my .svc file that in turn points to my Model.
Here's my question: I would like to use the rich features of DataAnnotations (System.ComponentModel.DataAnnotations) but where exactly do I put these attributes? If I decorate by Model with these annotations, I don't see them rendered in my [Service Reference]-generated proxy code. I just see my classes with its members, but no DataAnnotations (Reference.cs).
I know if I manually change the (Reference.cs) file and add some DataAnnotations, these changes to trickle throught to my Silverlight Client. I don't believe I should be updating generated code, i.e. proxy code w/in (Reference.cs). So, my question is, where in my Visual Studio structure of separated projects (Web, SL, Model, DAL), do I throw/extend this custom datasource (Model) to utilize DataAnnotations?
I would like something like this:
[Required]
public string FirstName
{
get
{
return this._FirstName;
}
set
{
this.OnFirstNameChanging(value);
this._FirstName = value;
this.OnFirstNameChanged();
}
}
I have a replacement code gen for producing ADO.NET Data Service proxy classes and adding in the validation automatically in my Niagara Project:
http://niagara.codeplex.com
I think checking this article out might give you some insight as to why Shawn posted his comment. The short answer to your question is. Follow the ModelView-View-Model (MVVM), style of silverlight development, then place DataAnnotations on the properties in your Model, its a huge topic and you need to read and understand it first. I suggest you check out RIA services,(i think its know as WCF services now), that will help you out alot if you want to propagate Validation logic from the WCF service, back to the client.
Related
I have a Silverlight application that is loading Entities from a WCF Service via DataBinding.
So I have several views with many textboxes whose textboxes contents are binded to a Entity properties.
I want to use Silverlight validation and I don't want to use the exceptions way (I have some entities with a lot of properties... and I don't want to repeat it every time I use it in a form...).
So I'm triying to use the IDataErrorInfo way, but I'm not sure how should I do it.
I think I should declare a client-side model with equivalent classes to the Service EF Model but implementing the IDataErrorInfo. This solution means duplicate the model code and make any way to translate from service model to client model.
The other solution could be to change the EF Model itself but I don't know if this is correct for the MVVM (this is really near to the view, isn't it).
Maybe there is another magical solution I don't know.
Any suggestions??
The recommended interface is actually INotifyDataErrorInfo
Which gives you a little more control and supports multiple errors. It's also a little bit easier to use in scenarios when you manually want to control when validation happens.
Basically, with this, you could create a validate method on your "client side" objects which goes through their properties, validates each one, and builds up a list of errors. (HasErrors becomes true, you notify ErrorsChanged and then the code that binds to your object does GetErrors.
With this way, you could build a validation engine and have each EF object poll your database for validation rules.
There's also this: http://msdn.microsoft.com/en-us/magazine/ee335695.aspx
If you have the option of annotating your EF classes on the client side instead of simply using the generated ones, you may be able to find an easy solution here.
I know this is slightly off-topic since you're using WCF
but if you were to use RIA Services, then it generates objects from your EF, and you can simply add some attributes to them in the RIA (it comes with comments telling you which attributes to use)
and it's very very simple.
but that advice is relevant only if you were to use RIA.
I've created a WCF RIA Service that I'd like to use with a WPF application. I've added several System.ComponentModel.DataAnnotations validation rules on the entities meta-data, all which work great on the server when I call .SubmitChanges(changeSet) from the client. I'd also like to validate my entities on the client side before I sumbit my changes to the server but I have no idea how to do so. Any help in this regard would be greatly appreciated! Thanks....
As far as I know, there is no WCF RIA Services for WPF (although I'd be glad to be proven wrong, as I am waiting for this...), so you have to do the client-side work yourself.
Use the VisualTreeHelper to go over every control in your form, and recursively if the control is a panel. For each control, have a list of potentially-bound properties (I guess there is only one in this case). For example, a TextBox will potentially have its TextBoxProperty bound, a CheckBox will have its IsCheckedProperty bound. Use BindingOperation.GetBinding to get a Binding instance, which gives you the Source and Path properties. Now use reflection on the source to see if there is a data annotation associated with it. If there is, check it.
Yes, it is a lot of code.
[Disclaimer: I'm ASP.NET MVC Developer]
Hi,
I'm looking for some best practices with implementing MVVM pattern with WCF RIA in Silverlight 4.
I'm not looking to use MEF of IoC for locating my ViewModels. What I would like to know is how to apply MVVM pattern with Silverlight 4 and WCF RIA.
I don't want to use other stuff like Prism or MVVM Light toolkit. I found many examples on Internet showing how it is wonderful to drag and drop a datasource on the view and the job is done (it reminds me about my first VB6 developments).
I tried to implement MVVM with WCF RIA and it's not strightforward at all. If I understand, the MVVM should contain all the logic in order to unit test it in isolation but when it comes to combine it with WCF RIA it's another story. I have the following questions.
Can I use a generated metadata as model ? It would be easier to use it that if I write all from the scratch.
As I saw the only way I could get data is through DomainContext or through direct binding in the view (local ressource). I don't want the direct binding in the view, not testable at all. On the other hand I can't use DomainContext, it doesn't expose any single entity !!! All I have is the EntitySet that I can bind to datagrid. How do I bind a single Entity to the DataForm from the ViewModel ?
How do I udpate the model to the database ?
How do I navigate from one Entity to a collection of it's items. For example if I have a Company Entity I would like to show a DataForm to update an entity informations and a datagrid to show companies adresses. When saving a form, I would like to save an information to Company and an information to adress about which adress was selected as active.
Please help me understand how to do it well. Or maybe I should drop the WCF RIA and to do it with WCF from scratch ?
What do you think ?
You might be interested in this session. It explains how to use the MVVM pattern with RIA WCF Services.
I found this post useful:
http://www.astaticstate.com/2010/04/silverlight-4-using-mvvm-patter-ria.html
Some random answers...
I don't think that MEF is particuarly well suited for Silverlight. It's primarily for desktop apps, and could be adapted for other uses where the plug-ins are in the local file system relative to the app.
MVVM requires that you understand roles. The "view" is your XAML and code-behind. The code-behind should handle events from the user control, but very little more than that.
The ViewModel holds the data that the user control will bind to. Generally, the ViewModel is bound to the View as its DataContext, so that everything in the form can databind to properties in the ViewModel. The ViewModel must implement INotifyPropertyChanged, and raise property changed events for every property that the form databinds to.
You'll probably want to create an ObservableCollection, using an EntitySet as your source. This will handle INotifyCollectionChanged for databinding purposes. If the entities in the EntitySet also handle INotifyPropertyChanged, then you're in good shape on databinding for collections.
You can create a property for an individual entity, and databind to that, assuming that change notification is also implemented (both for entity members, and for the entity property).
RIA Services will regenerate the DomainContext on each build, which helps a little in keeping it in sync. It's intended to be a service layer above an ORM, though, so your ORM or other data mapping will still have to be maintained by other means.
I haven't looked at the final release of RIA Services, but I wasn't hugely impressed with the beta version. I'd rather have good entity classes defined on the server, and share them with the Silverlight project. It's not easy to set up, though, and requires some non-trivial WCF that doesn't rely on service referernces. (RIA Services final release may have cleaned some of this up, but the native WCF service reference in Silverlight is pretty much evil, mainly because it doesn't automatically recreate generated classes, and it hard-codes the URI for the server-side service.)
Metadata was another problem with RIA Services beta. It's easier to attach metadata attributes directly to your DataContract class and the individual DataMember properties, if you control the entity source. Again, that may mean not using RIA Services. Writing a separate metadata class, as was required for the RIA beta, wasn't a good solution.
I ended up not using RIA Services for Silverlight 3, and didn't regret it. Here's an excellent article on WCF and Silverlight. Although it says Silverlight 2, it's still on-target for any Silverlight release.
I do recommend MVVM Light. Source is available on Codeplex, if that's an issue. It provides messaging and commanding support, as well as a ViewModelLocator; while the latter takes a bit of work to understand, it's really a good extension to the basic MVVM model.
Hope this helps.....
Just thought I would let you know about a project I am working on - just got our first release done. Provides a great simple way to approach MVVM for Silverlight + RIA Services specifically. Simplifies a lot of the MVVM stuff, and provides some more controller-like functions with the Notifications class. http://slmvvms.codeplex.com/
Following on from this initial investigations on Silverlight architectures, I have some new requirements to consider.
We expect our Silverlight client UI to be graphically heavy, with a GIS interface, multiple charts, gauges and datagrids arranged in a Widget style fashion. New widgets will be dynamically generated by the user.
Suppose a user wanted to dynamically create a chart widget from an existing datagrid widget pre-populated with data. It appears to me that if we were using a MVVM pattern with the view model on the server, this would result in an unnecessary call back home when the required data is already located in the client.
Now obviously the server needs to know about this new chart widget on the client, but how do I create the widget in the client first (with the existing client side data) and then notify the server about the new changes?
In our intranet, the network link between the client and the server is not particularly good so performance is critical.
It seems from my initial research that the common Silverlight architecture patterns call for as much of the business logic to be pushed back to the server. I understand the reasoning for this, but fear that it will really hurt the usability of our application.
Are there particular design patterns that address this issue? Is this 'client-binding' supported within MVVM, Prism or other common Silverlight architectures?
Is there a more formal name for what I am attempting to describe?
I am quite new to both Silverlight and design patterns such as MVVM, so please correct me if any of my assumptions are wrong.
The MVVM pattern is for separation of concerns. It does not define how or where you get your data.
The model, is data. It can be data you get from any arbitrary source. In silverlight, the most common way to get data is via a webservice (SOAP/REST). But your model can be any data from anywhere.
The view model is just another class that probably implements the INotifyPropertyChanged interface (So you bindings can automatically be updated). This class is an abstraction for your view's data. Let's pretend it has a string property called "FirstName".
The view is your UI (A user control in SL). You setup your bindings here to your ViewModel. IE, .
The view and view model are put together when you set your views DataContext. myView.DataContext = new MyViewModel(); There are many ways to set the DataContext depending how you want to set things up.
Prism is just a framework to help write decoupled applications in WPF/SL. It does not enforce the usage of any UI pattern (ie, MVP/MVC/MVVM). What it does come with is a bunch of classes can be used to assist with MVVM development, such as a mediator (EventAgggregator) and a dependency injection container (Unity).
So enough digressing...What I would suggest, is you have a web service where you can get all your data. You SL app would get that data (most likey the web services will be called in the view model). That data now exists on the client side and you can setup your VM to bind to this data in your view.
I have successfully created a asp mvc app which basically has interface, service and dataacces - AKA the repository pattern..
What would be the best way to call my service (my repository pattern) from an MVVM structured WPF app..
From what i see.. in the MODEL in wpf i presume i call my service (repository pattern) from the model and then return data to my viewmodel for displaying on the view??
Should this model be thin i.e. has little code and just call the service.. and return data to the viewmodel for processing or should the MODEL call the repository service and do the processing in the model before retruning to the viewmodel??
I am a little confused how i can use my WORKING repository pattern in the realm of a new WPF MMVM app i am designing...
Any ideas?
Thanks
I think you are complicating matters by focusing on the fact that your data access uses a repository pattern. It's irrelevant. You could be using Joe's Box' O' Data pattern and your underlying question would be the same. Let's forget you are using that pattern and focus on what you are doing: getting data from a data source.
When you get data from a data source, this is generally considered to be your Model. It's data, but it lacks certain behavioral things that make it appropriate for showing on the screen (lack of INotifyPropertyChanged implementation, for example). What people generally do with this is adapt their business objects into something that can be more readily used by a view (a view model).
You will use this technique regardless of the pattern in use for getting your data.