I'm starting to migrate one app to WP7 Mango now. One of the reasons is the database support :-)
Technically the database thing is really clear. But I'm a bit unsure where should I put my datacontext. I see primary two options:
global datacontext for everything
a separate datacontext instance per app feature
I would like to have some thoughts on that.
Thanks!
The demo included with the SQLite2CE tool might help you in that it gives an example of how to use datacontext and ViewModels. Visit http://sqlite2ce.codeplex.com/ and download the package, the linked articles on this page will also be a help. As a bonus, if you haven't yet converted your database from SQLite then the tool will help you with that as well.
If you take a look at the demo there's a MainViewModel (set as the datacontext of the application's MainPage.xaml) which contains an ObservableCollection for each referenced class of data. A second ViewModel is used to compile a custom set of data from the database but is still referenced though an ObservableCollection in MainViewModel. This way each control you wish to bind in XAML only needs to reference a column within the appropriate ObservableCollection object.
At the moment I'm would use multiple datacontext for the different features. I'll tried to use a single one through the singleton pattern. This caused some exceptions because you'll need to syncronize the SubmitChanges() calls - especially if different threads are used.
Related
Is localization a responsibility of the View or of the ViewModel? Initially, I thought that it clearly belongs into the VM, as it is just data that needs to be displayed by the view. What exactly needs to be displayed is not important to the view. In addition, I have made the experience that XAML is more brittle than ViewModel code. But in a discussion today, some people strongly believed that localization is the responsibility of the view.
Here's some of the advantages I see for both versions:
Advantages of putting them into the View:
ViewModel is oblivious of localization
You can see the resource key in the XAML
Less code
Advantages of putting them into the ViewModel:
View is oblivious of localization
The View does not need to know anything except for it's ViewModel
It's easier to combine and create more complex strings.
In a Wpf application that uses the MVVM pattern, should the localizable elements (string resources) go into the view, or into the viewmodel? Why? What other advantages and disadvantages are there for the two approaches?
Some background info after comments: Assume that the Localization-backend is based on resx (not LocBaml). In addition, assume there was a framework that (View-Variant) could either transparently replace resource-ids in the view with the string, or that (ViewModel-Variant) would automatically generated INotifyPropertyChanged events for localized properties on the ViewModel.
However, I am mainly interested in arguments why it's better from a conceptual or cleaner-code point of view, disregarding the backend.
Some resources belong to the View, and some resources belong to the ViewModel. I do not think there is a strict rule in that matter. Use your own judgment. Personally, I'm sharing the ViewModel's resource file with the View.
To correctly implement localization in your WPF Application as it was designed, you need to follow the set procedure, so there is not really a choice like you are suggesting. For one thing. you'll need to set the Uid property on all of your UI controls, so that clearly can't be done in a view model. Furthermore, it is common to put all localized string values into separate dlls, so again, you can't do that in a view model.
I don't have the time to describe exactly how to do it right now. Instead, for full details about localization in WPF, please see the WPF Globalization and Localization Overview page on MSDN.
I'm creating an application on which I want different users to use it. I want to insert a variable, only modifiable at development mode. I think maybe there should be a way of using the App.Settings of the WPF Application, but, after one hour googling, I don't have a clear idea yet.
So, I need:
A variable that makes the WPF Application run at administration or client scope
If I have that variable in a specific role, I want to disable some controls
Any idea on where to look for a solution for this?
Well you could add to the base class of your ViewModels a property which contains the value reflecting the mode. As next step you could bind the IsEnabled property of the controls, which shall have this behavior, on this property of their related ViewModel.
Since you don't want to provide different modes with different states a.s.o., this seems to be the best approach.
I'm new to MVVM and need a bit of help.
My application consists of a number of different windows which display controls allowing the user to edit the data in the Business layer.
At the moment, each time the user opens a new instance of one of these windows, a ViewModel structure - classes and collections mirroring the Business layer - is created from scratch and databound to the View on the window, and is also configured to access the appropriate parts of the Business layer.
This is quite sluggush at the moment, and I have a suspicion it is because the application has to wait until all the new ViewModels are created and configured every time a window is opened. I also notice the RAM gets munched up quite quickly too.
Would it be better to have a single ViewModel structure which is created when the application starts, and then all windows and controls refer to this single instance? What is the convention for MVVM?
One ViewModel per view is pretty standard. You don't want to share instances of ViewModels, since they are (usually) stateful.
I would look deeper into the sluggishness before concluding it's the creation of the ViewModel that's causing it. Profile the application with a tool, set some stopwatches, or debug the app and see what the bottleneck is.
do you need to recreate your viewmodels every time you access your views?
if not it seems you use view first approach, maybe you should then use a viewmodel locator?
you can also take a look at viewmodel first approach, maybe this fits more in your application.
To preface, this is my first attempt at MVVM... I buy it, I'm just having a little trouble implementing it.
I'm building a utility to assist with managing a course. I have a COURSE object which contains a few properties and methods as well as a collection of MODULES. Each module has a few properties, methods and a reference to a PRESENTATION object and LAB object (each of those has a few properties. I first implemented the modele and wrote all unit tests.
My challenge is now in implemting the UI (V & VM)... specifically the view-model part of the MVVM.
The UI allows you to create a course, see the modules and then have a master-detail view into each module where you can set a few properties and such. For my view model, I created an object to encapsulate the COURSE model... exposing a few properties including an ObserveableCollection of the course modules.
I've run into a few things that are throwing me for a loop and looking for some help:
I'm not sure if I went about my VM part correctly by creating something that encapsulates the COURSE model. Because I need to access MODULES in the course as well as LABs and PRESENTATIONs in the COURSE object. Does that mean I need to create VM's for each of those as well? Seems like I'm going about this the wrong way as this approach means I'm going to encapsulate every object in the model, same goes for each method and property?
When showing the modules in the UI of the app, I need to move things up and down in the order. The methods that do this are baked into the COURSE model. The trick is when I use these methods from the view, it isn't updating the view because the courses object lives in the VM, not in the M. I can "fix" this by setting the DataContext of my listview to null and then resetting it to be the same as the hosting window (which is the COURSE), but that isn't ideal. The modules are an observable collection, but they won't update because I'm doing the work at a lower level.
Seems I'm going about my VM a bit wrong... something tells me that not everything from the model should be encapsulated within it.
You don't NEED to create VMs for Modules or Labs, having Observable collections of each is enough. But...If you need to have extra powers on each of these objects, you can have collections of ViewModels instead. (as the Josh Smith example do)
If your logic is in the model, you need to refresh the ViewModel when you do changes to the model.
Im writing a wpf project and using the MVVM paradigm, what i was wondering is if i should write my view model classes in their own project.
Advantages i can see is that your ui project would never have to know about your business logic. (not have a reference to it)
however if i want to use the ICommand interface in my view model i still need a reference to PresentationCore which may indicate that i should be in my ui project.
comments suggestions most appreciated.
As soon as you reference PresentationCore in your ViewModel (which is currently unavoidable if you want to use ICommand) you are leaking all manner of undesirable View-related features into your ViewModel. For example, MessageBox.Show, when you see this called in a unit test it drives home why it's bad.
To answer the question, yes keep your View and ViewModel in separate projects. I wondered this myself but after going down the separate projects route it took me awhile to appreciate but it has been really valuable in making me stick to a clean MVVM solution, and the lessons from this have greatly improved my overall solution architecture. It's all about reducing dependencies on unnecessary assemblies using interfaces and if necessary the Adapter pattern. One example is that my View project, being an entrypoint has a reference to Ninject, but I don't want my ViewModel to have that reference. Otherwise someone might come along and use the Ninject static Kernel directly.
Regarding ICommand, I don't know the history having only used WPF since 4, but it feels like MVVM was an afterthought. I'm not sure why else Microsoft would have put this interface in PresentationCore. I'm hoping this will be addressed in a future release with a separate assembly for the ViewModel layer.
I don't think there's an overwhelmingly compelling way to do it one way or the other. I tend to keep VMs and their views in the same assembly, but within a different folder structure. For example, I might have ViewModels/Foo/Bar/CustomerViewModel and Views/Foo/Bar/CustomerView.xaml.
I don't think there's a problem splitting out the views and view models either. Having the VM assembly reference view-related assemblies such as PresentationCore is only natural. After all, your view models are part of your view layer.