In MVVM pattern I don't want to think about the view while creating the model. So I use public properties with data stored in ILists and so on.
But then my viewmodel isn't informed of changes done to these lists on model side.
Should I use ObservableCollections in my model instead? But this seems strange to me.
Yes, you should use ObservableCollections. I don't know what would be strange about this? All an ObservableCollection does is notify any listeners of changes. That doesn't necessarily have to be a UI.
Your ViewModel shouldn't know anything about the actual View using it, but as it's a ViewModel, it is ok for it to assume something is going to use it, so ObservableCollection is the way to go and also, as far as i know, common practice.
Also, the listeners know exactly which items have been added or removed, so there's no need to update the entire list when changes occur => better performance for updates. That's also what Microsoft says (can't find the article about that right now though)
this is also the reason why you see most people implement INotifyPropertyChanged on their data model, because you want the viewmodel to be notified everytime the data model changes.
Related
I'm quite confused about the architecture of my MVVM application (formerly WinRT, now targeting UWP) concerning data access. I'm quite unsure how to propagate changes across the UI and where to put access to the data layer.
Here's the basic architecture:
Model layer: contains models that only have auto properties (no navigation properties that reference other models, just Ids; so they are basically just representations of the database). They don't implement INotifyPropertyChanged.
Data acccess layer: A repository that uses sqlite-net to store models in a database. It exposes the basic CRUD operations. It returns and accepts model from the model layer.
ViewModels:
ViewModels for the Models: They wrap around the models and expose properties. Sometimes I two-way bind content of controls (e.g. TextBoxes) to properties. The setters then access the data layer to persist this change.
PageViewModels for Views: They contain ViewModels from above and Commands. Many Commands have become very long as they do the data access, perform domain specific logic and update the PageViewModels properties.
Views (Pages): They bind to the PageViewModels and through DataTemplate to the ViewModels for the models. Sometimes there is two-way databinding, sometimes I use Commands.
I now have several problems with this architecture:
Problem 1: One model can be represented on the screen at several palaces. For example, a master-detail view that displays a list of all available entities of a type. The user can select one of them and its content is displayed in the detail view. If the user now changes a property (e.g. the model's name) in the detail view, the change should be immediatelly reflected in the master list. What is the best way of doing this?
Have one ViewModel for the model? I don't think this makes much sense, as the master list needs only very little logic, and the detail view much more.
Let the model implement INotifyPropertyChanged and thus propagate the change to the ViewModels? The problem I have with this, is that the data layer currently doesn't guarantee that the objects it returns for two read operations on one model id are identical - they just contain the data read from the database and are newly created when they are read (I think that's the way sqlite-net works). I'm also not really sure how to avoid memory leaks happening because of all the PropertyChanged event subscriptions from the ViewModels. Should I implement IDisposable and let the PageViewModel call its children's Dispose() method?
I currently have a DataChanged event on my data access layer. It is called whenever a create, update or delete operation occurs. Each ViewModel that can be displayed simultaneously listens to this event, checks whether the changed model is the one its the ViewModel for and then updates its own properties. Again I have the problem of the memory leak and this becomes slow, as too many ViewModels have to check whether the change is really for them.
Another way?
Problem 2: I'm also not sure whether the place I access data is really well chosen. The PageViewModels have become extremely convoluted and basically do everything. And all ViewModels require knowledge of the data layer with my architecture.
I've been thinking of scrapping data access with sqlite-net and using Entity Framework 7 instead. Would this solve the problems above, i.e. does it guarantee object identity for one model when I use the same context? I also think it would simplify the ViewModels as I rarely need read operations, as this is done through navigation properties.
I've also been wondering whether having two way databinding is good idea at all in a MVVM application, as it requires the property setter to call the data access layer to persist the changes. Is it better to do only one-way binding and persist all changes through commands?
I'd be really happy if someone could comment on my architecture and suggest improvements or point to good articles on MVVM architecture that focus on my problems.
Have one ViewModel for the model? I don't think this makes much sense, as the master list needs only very little logic, and the detail view much more.
ViewModel is not dependent on the model. ViewModel uses the model to address the needs of the view. ViewModel is the single point of contact for the view so whatever the view needs the viewmodel has to provide. So it can be a single model/multiple models. But you can break down a single ViewModels into multiple sub ViewModels to make the logic easier. Its like detail pane can be separated into a user control with its own view model. Your master page will just have the window that will host this control and the MasterViewmodel will push the responsibilities to the sub ViewModel.
Let the model implement INotifyPropertyChanged and thus propagate the change to the ViewModels? The problem I have with this, is that
the data layer currently doesn't guarantee that the objects it returns
for two read operations on one model id are identical - they just
contain the data read from the database and are newly created when
they are read (I think that's the way sqlite-net works). I'm also not
really sure how to avoid memory leaks happening because of all the
PropertyChanged event subscriptions from the ViewModels. Should I
implement IDisposable and let the PageViewModel call its children's
Dispose() method?
The danger is not using INotifyPropertyChanged, but as your rightly said its with the subcribing and unsubscribing. Wherever there is a need to subscribe to any event - not only INotifyPropertyChanged you need to use IDisposable to unsubscribe itself and its child ViewModels. I am not clear on the datalayer you describe, but if it publishes the property changed event for any modification I dont see any problem using INotifyPropertyChanged.
3.I currently have a DataChanged event on my data access layer. It is called whenever a create, update or delete operation occurs. Each
ViewModel that can be displayed simultaneously listens to this event,
checks whether the changed model is the one its the ViewModel for and
then updates its own properties. Again I have the problem of the
memory leak and this becomes slow, as too many ViewModels have to
check whether the change is really for them.
As I said earlier, if you handle the subscribe/unsubscribe properly for all models you need not worry about performance issue of INotifyPropertyChanged. But what might be adding to the problem is the number of calls you make to the database for requesting data. Have you considered using Async...Await for the data access layer which will not block the UI for any update thats happening. Even if the data update is slow a reactive UI which doesnt get blocked by the data calls is a better option.
So try adding a data access service which is abstracted over the DAL layer and provide a asynchronous approach to accessing the data. Also have a look at the Mediator Pattern. That might prove helpful.
I'm also not sure whether the place I access data is really well
chosen. The PageViewModels have become extremely convoluted and
basically do everything. And all ViewModels require knowledge of the
data layer with my architecture.
2 main problems i see,
If you feel the PageViewModel is too huge break down into sub view models of manageable size. Its very subjective, so you have to try to see what all parts can be broken down to its own component/usercontrol with its own viewmodel.
When you say ViewModels require knowledge of data layer, I hope you mean they are dependent on a Interface that manages the DAL layer services and doesn't have direct access to class with CRUD methods. If not try to add an abstract layer which does you actually do in your view model. And that will handle the DAL CRUD operations.
I've been thinking of scrapping data access with sqlite-net and using
Entity Framework 7 instead.
Don't try to replace sqlite-net with EF without hard evidence. You need to measure performance in your app before trying to jump into such big changes. What if the problem lies in your code rather than the component you are using. First try to fix the above mentioned issues then you can segregate the DAL layer via interfaces and replace it if needed.
I've also been wondering whether having two way databinding is good
idea at all in a MVVM application, as it requires the property setter
to call the data access layer to persist the changes. Is it better to
do only one-way binding and persist all changes through commands?
If you are making a call to database directly everytime you make a change to the field/ for every key stroke then its a problem. Then you should have a Copy of the Data Model and persist the changes only when you click the save button.
what goes where?
This is a short description of my C# project:
I have a mechanical construction (only one in the whole program), described by some 20 to 30 parameters (deimensions, material parameters etc.), that may, as a complete set, come from an input screen or from an XML file (Deserialized). These parameters must then be processed in a calculation to generate output, that goes to a JPEG file and also to an HTML file.
The View is clear: it's the IO screen.
The View needs an ViewModel where the Properties are. Maybe:
My Model is the construction at hand, that is described by its parameters.
Those parameters however, are the same ones that are gathered from the IO screen , the View or from XML.
Some output (the JPEG file) also goes the View. It might be a Property that Notifies it's changed.
Now my question is, do I need a Model at all, because the ViewModel has all the properties already.
Or, do I need a ViewModel at all, because my Model has all the Properties to be Viewed. I could define a Model in the ViewModel (like it is always done in MVVM) and use the Model as a DataContext for the View. But that last option would make the View aware of the Model: not in the MVVM spirit.
I've written this multiple times already, but I'll do it once more...
The main reasoning behind MVVM is to separate layers and to avoid tight coupling as much as possible.
That said, View is, as you've correctly guessed, the UI. Things your user sees. It doesn't matter if it's a Windows, a Page, a custom control, webpage or even a console (when we talk about MVVM in a broader context).
ViewModel is a mediator between your model and the view. It takes, combines and manipulates your methods and properties from the model for the purposes of the View. It doesn't care how, when and where are these used. It also can trigger actions on the model side, for instance call services that take care of updating your database.
Model is EVERYTHING that isn't tied to the specific platform. It's classes of your business logic, it's database entities etc. It's basically your application stripped of any ties to the UI implementation. This is what people get wrong and think that model are only database entities. That's simply wrong!
To answer the question you've asked: "Now my question is, do I need a Model at all, because the ViewModel has all the properties already."
Yes, you should, otherwise you'll end up coupling the view directly to the model and that's violating MVVM principle. Your View shouldn't know ANYTHING about the model directly. As far as View cares, every one of the properties and methods can be coming from a different project. It won't change a thing and the view will still function the same.
You maybe don't see it yet, but in the future it will make your life much more easier. The code becomes easily maintainable if done correctly, much more readable etc.
In addition of what #walter said, you can check this Codeproject entry which explains flawlessly the difference and a little bit more. That article helped me to undestand when I was beginning:
http://www.codeproject.com/Articles/100175/Model-View-ViewModel-MVVM-Explained
In short:
Model: A class that represents data, it shouldn't do anything. It's good practice to implement INotifyPropertyChanged, however it's not required if you don't need to change the data from the View.
ViewModel: A class that exposes the model as a public property so that the view can bind to it. It should contain methods that interact with the model. It could also contain properties of it's own.
View: Binds to the ViewModel, where it can access the model, and ViewModel properties.
So, I'm on to the next phase of my education and have reached a bit of a blocker related to my use of SQLite (this is for a universal app, with my current focus being on the Windows Phone side of that solution). My question is somewhat independent of SQLite but I will use it as an example.
I am looking at SQLite as the database for my app (based on various suggestions and comments here and elsewhere). Specifically, I am designing my view -> viewmodel -> model and I'm not sure of an appropriate pattern for passing around ObservableCollection.
Let me start at the model. I am making a call to SQLite-net's QueryAsync() method. So, buried deep in the model I have any await on the call to QueryAsync(). The method in which that lives (let's call it GetData(), for simplicity) is marked with async. So, that's the model.
Up at the view level I need to bind to a property of the viewmodel. Let's call that property GetDataVM(). Since it's a property I use a getter - and, as far as I can tell, I can't use await in getters. Is that true? Given the asynchronous call in the model - QueryAsync() - it seems I need an await, right?
I am sure I have some basic assumptions wrong here. But the basic principle I am trying to understand is what a control in my view must bind to when that property calls a method in the model that includes an async method.
I'm not finding this particularly easy to explain :) But, stepping right back, what I want is very simple, conceptually. I want a control to bind to a viewmodel property that, in turn, retrieves data from the model, which retrieves data from SQLite.
And I'm confused :)
Any help would be most appreciated (probably starting with clarifying questions about what the heck I'm trying to achieve :)).
Thanks.
I have an MSDN article on this topic.
The gist of it is this: as others have noted, a property read should be an immediate operation, whereas an asynchronous operation is (generally speaking) not immediate.
So, what you first need to do is decide what your UI will look like while the data is loading. When your VM loads, it should initialize its data in that "loading" state, and when the data arrives, the VM should update to the "ready" state (or to an "error" state if the operation failed).
In my MSDN article, I introduce a NotifyTaskCompletion<T> type that is pretty much just a data-binding-friendly wrapper around Task<T>. This allows you to do the state transitions via XAML bindings.
You are right, getters are not async. I would also refrain from trying a hack to make them work that way.
It is considered bad practise to have long running getters and good practise to wrap long running processes as await able asyncs.
You can see why the two are not compatible.
Instead, is it possible to trigger your async call from a command? That way you can make the call async and just assign the result to the property via the setter, that should call INotifyPropertyChanged PropertyChanged event to update your UI.
In general it is the ViewModel's responsibility to load the model (of course it could pass this responsibility to a repository class)
This way the ViewModel can contain the awaits and the Model can consist of plain data containing classes.
The View and ViewModel decide when to sync the model to and from the data source.
The role of the ViewModel is to mediate between the Model and the View. Most of the times I do not design the Model but accept it as a given from the data source and in many cases the Model is generated from a contract by a tool (Entity Framework, Web Services, ...) So I treat the Model as a dumb data container that changes when the data source changes.
The design of the View is driven by the user (requirements) so I am not in control of that either.
The ViewModel is where I get to design and code the transition between View and Model so that is also where I decide (based on user and technical requirements) when and how to load the data (Model) and transform it to match the structure needed by the View.
Many times the actual connecting to the data source is coded in a repository class so the ViewModel is not aware of the actual data source (connection/technology) This way it is easier to connect to another data source to support unit testing or the actual migration to another data source.
Try to put one responsibility in each class/layer.
Im using MVVM.
I am implementing my data as OberservableCollections in Model, and I want the ViewModel to listen to and update any changes in the OberservableCollections of data in Model.
I know you have to implement some Actions, e.g. inset, add, etc in ViewModel. But I can not find any tutorial on it, can someone please provide some ideas, thanks :)
Since you are new to the MVVM pattern, read this post by Jeremy Likness, a Silverlight MVP. He gives basic examples of ViewModels, views, models, binding, commanding, etc.
As far as passing the model objects to the ViewModel, that all depends on where the model objects are coming from. For example, in most LOB applications, you will get data from the server via WCF, which introduces a layer of complexity to the pattern and the implementation.
If instead you mean "how does my ViewModel get notified when the user changes some data on the view", then that notification comes from your ViewModel implementing INotifyPropertyChanged, and your View binding to the properties exposed by your ViewModel. I think reading Jeremy's blog post will clear a lot of this up for you.
I'm finding myself with a bit of anarchitectural problem: I'm working on a smallish project that, among other things, involves data entry and persistance, with a DAL using a webservice with a custom JSON protocol. So far, so good, and it would be a relatively simple matter slapping together some quick&dirty DataTable + DataGrid code and be done with it.
This is a learning project, however, and I'm trying to figure out how to do a somewhat cleaner design, specifically MVVM with a WPF gui, using the Caliburn.Micro framework. The server part is fixed, but I'm doing the entire client part, including the DAL.
With the DG+DT combo, it's pretty easy doing a bunch of edits in the DG, and when user commits simply iterate the Rows, checking the RowState property and firing create/update/delete DAL methods as necessary. DataTable doesn't seem very MVVM databinding-friendly, though, and the ViewModels involved shouldn't care what kind of UI control they're being used with... given that persistance is done through a webservice, requiring batch commit of modifications seems reasonable enough, though.
So I'm pondering what my design options are.
As I understand it, the DAL should deal with model-layer objects (I don't think it's necessary to introduce DTOs for this project), and these will be wrapped in ViewModels before being databound in editor ViewModels.
The best idea I've been able to come up with so far is to do a clone of the items-to-be-edited collection when firing up an editor ViewModel, then on commit checking the databound collection against the copy - that'll let me detect new/modified/deleted objects, but seems somewhat tedious.
I've also toyed with the idea of keeping IsModified and IsNewlyCreated properties (I guess those would go in the ViewModel?) - keeping track of deleted items could probably be handled by keeping the editable items in an ObservableCollection, handling the CollectionChanged event, and adding deleted items to a separate list?
As you can see, I'm pretty unsure how to handle this, and any suggestions would be greatly appreciated :)
First of all
1- Don't do any changes untill you reached a point where you can't live without code changes.
2- As you already said that , you are creating a learning project and you want more modular application so my thoughts would be revolving around how to make my application more modular first before going deep into implementational details.
3- Have you considered using Prism + MVVM framework?
4- I would still suggest that in your ViewModel , you can still use DataTable to bind the data to the grids and byusing DataTable.GetChanges() method will give you all the changes in the table so you don't ever need to maintain boolean varaibles like IsNew or IsModified.
5- If you are not convinced using DataTable yet than use ObservrableCollection to bind data to the grid. ObservrableCollection does not notify indivisual item changed , it will only notify when item are added or removed.