Short question:
Do any of MS's built in Data Objects support INotifyPropertyChanged?
Long explination:
So I'm going to be displaying alot of data with databound controls.
The data is going to be chaging somewhat frequently with user interaction.
The application is a basic windows form app.
Rather than wire up events for all the data to the display controls I'm hoping that I can use data objects that implement INotifyPropertyChanged, that way the controls don't need to know the how, when or why their data changed just that they need to update themselves.
Sanity check:
Am I even barking up the right tree here?
The point of INotifyPropertyChange is to report property changes. To that extent, it's supposed to be implemented by specific model classes, not by general-purpose data objects. A more general solution for such objects is provided in form of PropertyDescriptor.AddValueChanged - since PropertyDescriptors can represent "virtual" properties, such as DataRow fields, or WPF attached properties.
I have been working for a few months on a rather large windows forms app, and we are using DataBinding and INotifyPropertyChanged for everything. It works really well, and I have no real problems to report. We are using our own classes, because there really isn't a data layer in this application, so I don't know for sure about the MS data classes.
BindableCollection< T > implements INotifyPropertyChanged
Related
I need to build our future business applications with WPF using MVVM.
My typical application consists of several windows/tab pages with grids and form style windows. Both edit windows and grid windows can be different depending on the logged in user, so most of them will be built datadriven.
And I'm trying to write as few code as possible, as not written code is the only one to be guaranteed error free .
So, now my question: how to structure the entire thing?
The View is clear to me - is is built using XAML or by code.
The ViewModel should contain the business logic and the validation rules and should let feed the View the data, and should contain the commands for the actions.
So, where to put the data? A select returns a DataTable. Should this datatable exposed through the ViewModel to the View for the grid windows?
And for the form windows? Should the single DataRow exposed trough the ViewModel to the View?
Are there other helper or intermediate classes needed?
Thank you for any useful suggestion!
Wolfgang
Its best way to go with WPF and MVVM,
I suggest before you start go thru the basics of MVVM. for your reference you can understand better here
The preferred UI paradigm in WPF is to have tab controls and grids in a single window, something like this:
You don't have to stop there, you can nest them as deeply as you need to for the sake of clarity.
I'd like to create a Silverlight app using WCF Ria Services and the MVVM design pattern.
The main page of the app will consist of a "shell" and a large number (10s or 100s) of objects of different look (shape/size/properties) linked to each other (forming a sort of graph).
These items need to be mouse-draggable and their current position/state needs to be saved to the back-end database.
I feel that the best way to achieve this would be to have a small ViewModel and View for each item displayed, put all the important properties into the ViewModel and then somehow display all these Views in the main "shell".
However, I don't know how exactly this could be achieved. I considered using MVVM Light, but didn't find any example that would show something similar.
Can anybody point me to some examples or ideas about how this could be done?
"When all you have is a hammer, everything looks like a nail" :)
MVVM is not designed to manage graphic intensive situation like the one you describe. It is a glue for stitching together high-level concepts in a flexible manner. With MVVM you are adding overheads that will impact performance (e.g. binding uses reflection behind the scenes). The more objects involved, the greater the impact.
The best starting point I can suggest is to imagine what you need from a 3rd party control (e.g. a custom control/container) and, if one does not actually exist already, build it as if it were a third party custom control.
You will find in practice that custom controls are seldom based on MVVM, for performance reasons if not just because "they often don't need it". They may well expose MVVM compatible properties for the external interface, but not for the low-level internals.
MVVM is a relatively high-level technique. Do not feel you have to implement it on everything.
Following MVVM do the next:
Model - create model object which will be responsible for fetching and persistence coordinates of the shapes on the screen;
View Model - one view model which will initiate fetching and persistance model objects;
View - in your case, it's a place where you do most of your work. Create custom control based on ItemsControl with Canvas panel. Custom control should pass collection of the model objects in ItemsSource, allow to drag and drop containers and call the view model command when user drops container in some place
Have a look at the Telerik controls, specifically radTileView, this seems to have the functionality that your looking for. They also have a persistance framework that should allow you to save the position of the tiles back to you database.
I'm studying WCF and WPF. I've learned a lot by doing sample projects, but I'm having trouble putting everything together. It would help if I could paraphrase my understanding of proper WCF/WPF structure and invite others to confirm or correct my ideas. Here is a very broad description of how I expect my next project to work:
My persistent data will be stored in a SQL Server database. I will create a WCF Service Library which serves as an interface to the database, solving security issues and recasting the relational data into an object-oriented entity model. My application will read data through the WCF service into a memory structure which might be customized somewhat for the needs of my application, but will basically consist of one ObservableCollection for each of the entities in my data model. Because the data will be stored in ObservableCollections, I will be able to use event procedures to respond to data changes that trigger business processes. Simple user interface elements will bind directly to the collections. More sophisticated user interface elements, like a TreeView, will require another layer, called a PresentationModel or ViewModel. In the case of a TreeView, the TreeView will bind directly to the PresentationModel, and the PresentationModel will bind directly to the collections.
Have I described everything correctly?
-TC
There is nothing technically wrong in what you wrote.
Things that feel off:
... solving security issues...
Scares me because it implies, to me at least, that you will have no security issues. I would have phrased it as
provideds a centralised system for authentication and authorisation to the data from all interfaces
I would definately make use of the MVVM pattern, allow a ViewModel to expose your collections and properties that your UI binds too, you seem to have a grasp of that pattern from what you have described.
Is WCF really required for your data layer? Have you looked into Entity Framework at all?
Simple user interface elements will bind directly to the collections.
I'd advise slightly against the above. A decent model to follow is the MVVM (Model-View-ViewModel) pattern. It sounds like you've read a bit about this considering your ListViews are going to be contained in a ViewModel. I would also have your raw data models exposed to a ViewModel, and have your View bind to that. So, for your raw data models, use them like you intend to do with ListViews.
Other than that, sounds like you're spot on.
I'm using EntityFramework for data access and wpf as UI. If I bind WPF components to navigation properties of my entity classes(usually EntityCollection<EntityClass>, exposed as IList<T> in service layer), UI is not updating the changes. I know i have to use ObservableCollection<T> or such, but I need some guidance on how to use it without iterating back and forth upon save and retrieval processes.
(As you guessed, I'm new to WPF; so target your answers for a WPF beginner)
You don't have to use ObservableCollection. WPF actually depends upon INotifyCollectionChanged, which ObservableCollection implements. So if you create a wrapper collection which implements this interface and forwards the operations onto the EntityCollection and raises the events, you should be good (as long as you modify the collection via the wrapper and not the underlying collection. A similar concept is used for read-only collections (wrap an existing collection and interact with wrapper), simple Decorator pattern.
You can't use it directly (and have the changes be reflected).
Here is a link that explains how someone else solved this problem
I faced the same problem in Silverlight LOB applications
I've created a silverlight library called ObservableCollections accompanied with visual studio 2012 addin and NUGet support, to generate the boilerplate code in order to wrap the EntityCollection with ObservableEntityCollection class, I know your question is about WPF but it could help.
http://observableec.codeplex.com/
This question already has answers here:
Why use MVVM? [closed]
(13 answers)
Closed 2 years ago.
Why we go for MVVM over MVC or MVP while dealing with WPF?
What extra benefit we get by using this?
Edit:
To be honest , today I had an interview and I have been asked this question. I answered like INotifyPropertyChanged , ICommand,IValue Convertor.. but he was not satisfied. Henceforth I have put up this question
Thanks in advance
I'll point you to a particularly useful video by Jason Dolinger.
Coming from a WinForms world, implementing any MVX style pattern seemed like more hassle than it was worth but after working with WPF for a couple of years now, I can honestly say that I wouldn't consider anything less. The whole paradigm is supported out-of-the-box.
First off, the key benefit is enabling true separation between the view and model. What that means in real terms is that if/when your model needs to change, it can without the view needing to and vice-versa.
Secondly, while your model may contain all the data you might need in your view, you may want to abstract that data in such a way that your model doesn't support. For example, say your model contains a date property. In the model it can exist solely as a DateTime object but your view might want to present it in a completely different way. Without the viewmodel you'd either have to duplicate the property in the model to support the view or modify the property which could seriously obfuscate the 'model'.
You can also use a viewmodel to aggregate parts of your model that exist in separate classes/libraries to facilitate a more fluent interface for the view to deal with. It's very unlikely that you'll want to work with data in your code in the same way that a user will want to or will want that data presented to them.
On top of that, you get support for automatic two-way data binding between the view and viewmodel.
There really is a whole bunch of extra stuff that I could bang on about but Jason say's it far better that I could so my advice is watch the video. After a few days of working like this, you'll wonder how you ever got by without it.
Good luck.
These are mine specific to MVVM
Increases the "Blendability" of your views (ability to use Expression Blend to design views). This enables a separation of responsibilities on teams that are lucky enough to have a designer and a programmer... each can work independent of the other.
"Lookless" view logic. Views are agnostic from the code that runs behind them, enabling the same view logic to be reused across multiple views or have a view easily retooled or replaced. Seperates concerns between "behavior" and "style".
No duplicated code to update views. In code-behind you will see a lot of calls to "myLabel.Text = newValue" sprinkled everywhere. With MVVM you can be assured the view is updated appropriately just by setting the underlying property and all view side-effects thereof.
Testability. Since your logic is completely agnostic of your view (no "myLabel.Text" references), unit testing is made easy. You can test the behavior of a ViewModel without involving its view. This also enabled test-driven development of view behavior, which is almost impossible using code-behind.
The other two patterns are really sort of separate in terms of the concerns they address. You can use MVVM with MVP and MVC (most good samples out there do some form of this).
In fact, MVP (w/ a Passive View, rather than a Supervising Controller) is really just a variant of MVVM, in my opinion.
WPF has better databinding than any other UI framework, which MVVM would be unruly without
MVVM provides unit testability and excellent view-agnosticism, which make it a good thing to use
Baked in support for ICommand and INotifyPropertyChanged are the two biggest benefits. Using MVVM makes it really easy to wire up the commands and plug data into the WPF UI. Things just work.
I personnaly see MVVM not as a benefit, but as an obligation for those who want to use WPF cool features.
WPF is very very heavily built with data binding at the core, to enable separation of UI from Model. But the way data binding is technically done in WPF is somewhat special, as it's tied to classes like:
DependencyProperty
INotifyPropertyChanged
ObservableCollection
Because of this you just can't really write a model the way you want using standard .NET technology. For example, the WPF TreeView is almost impossible to use w/o using data binding and templates. You just can't populate it simply like you would from a generic model in Winforms for example. It must be bound to a hierarchical model using ObservableCollection to represent a node's children.
So let's say V represents the XAML code and it's code-behind counterpart (so it's tied to WPF as a technology), and let's say M represents your model (so it's not tied to WPF UI technology in anyway).
Well, you'll never have this working properly under WPF with only these V & M.
You must add something between the two. Something that's WPF-compatible and understands your model. Something that speaks DependencyProperty, ObservableCollection and INotifyPropertyChanged. That's what's called VM.
As a side note, an alternative to MVVM is to build a V & M (w/o VM plumbing) combination with M being WPF-compatible but still with a reasonable UI independency. Historically, ObservableCollection was in the WindowsBase.dll assembly (that was shipped with WPF), so it really looked weird to bind a generic model to something tied to a UI technology. It's been moved back to System.dll since. Even then, it's sometimes hard to keep a pure VM model w/o tweaking the M specifically for WPF...
The ability of XAML code to databind, as well as the existance of triggers will break the MVP and MVC Patterns.