I'm trying to develop a WPF application - actually it's more a tool - using the MVVM pattern. I've read several articles, watched videos, posted questions but somehow I feel that my approach to or understanding of this MVVM thing is not "the right one".
I'll start from the UI. In a first stage the UI shall display the following:
Group box with
text box for the username
text box for the password (let's ignore the PasswordBox for the start)
Group box with
combo box for a list of project names available for this user (will be retrieved from a webservice)
button "Login" for logging in to the selected project
button "Logout" for logging out from the current project
So I would identify the following data that need to be handled:
A string for the username
A string for the password
An ObservableCollection<Project> for the list of projects
A Project object representing the active project
A boolean if logged in to a project or not
My worries, I have no idea how I should structure or design this following MVVM. How many views, viewmodels and models should I use here? Of course, the application will grow but not this much. Let's stick to the above.
There is no right or wrong answer to this
Think of Views, ViewModels, and Models as cut off points. They allow you to modularize your application versus taking a non-reusable monolithic approach.
In general, ViewModels to Views is 1:M however reality is that most of the time they are 1:1 relationship. The ViewModel and View are where the bulk of work resides, with the Model acting as nothing more than a POCO which implements INotifyPropertyChanged for binding needs.
In your example I would use a single View backed by a single ViewModel and multiple Models as is needed (Project, UserCredentials, etc...). You may have services which perform the actual login effort however you can perform that work in the ViewModel.
Related
I’m refactoring a big view model and it's associated XAML page. I use Prism. The main page has a clear functionality, create an avatar. There are steps to create the avatar like take the picture, edit the picture, etc. I have now a detail side bar which controls the navigation for the steps and a main content area which I show different content depending on these steps. I hide/show the appropriate views depending on the step. The project grew and now I have a 2000+ line view model and a huge XAML file.
What I ended up doing after some research is creating ContentViews for each step (showing and hiding them for each step again), so the XAML get's modularized for each step and also a View Model for each step. I was successful in binding the ContentView to each ViewModel but now I have problems communicating the different View Models information.
As before everything was in the same View Model, all views could share the same bound properties if needed. Now, as each view model is independent I need to find a way to properly share this information. My first approach was to use the Messaging Center. This way I can send the information i need to share to the view model that manages the navigation between steps (NavigationViewModel) and this can send this information to the following view models.
The thing is that I don't really like this solution as I find it too complex and will end up with a lot of code in the NavigationViewModel to subscribe/send to each sub-viewmodel to pass the shared information.
So my question is, do you know any other way to ease the communication between the view models?
I even thought about using partial classes to 'hide' my big view model complexity, but I think this is not a good idea.
Recenlty i came across the same problem,my ViewModel became really huge(with hundreds of properties) .So what i did is :
Created an Interface class.Putting all the common properties in there.Let's say IA.
Created another class inheriting IA.
And now multiple classes are inherting IA,reducing the overall properties numbers.
I am building a project browser, which looks a bit like a simple file explorer. In order to make the project management easier, I would like it should be able to open more than one instance of views, so the user can copy/paste from one view to the other without much scrolling in one view. The "Project Browser" mainly consists of a tree-control, which represents the structure of the project. There can be more than one project, but only one project is shown in the tree-view. I am not using any framework (only Telerik Controls, but they don't affect the Problem) but I am aware of the MVVM Pattern.
The data shown in the view is gathered from a Request Layer which does the DB Stuff. Since it is also possible, that the shown projects can have many items in a node/folder, data is loaded on demand. Whole data is not present after initializing.
Now my problem is, if I bind all project browser views to the same View-Model, they began behave like "twins". If I select one item in one view, it will be selected in the other views too. That's not what I need. I need to share the data across all views, but not the visual state of the data.
I think, I could handle it if I create one View-Model instance for every view instance. But then I have to wire up many events, because all data for every View-Model have to be synchronous. Each item and Child-Collection in the Tree/View-Model have to be connected to its counterparts in the other instances. I am wondering if there is a simpler/other solution for my problem (or if I am misguided at any other point).
I'm currently creating a "wizard" to create new projects inside my program. I have a solution that is almost done but it doesn't feel "right" and start to think about other solutions. Maybe should note that I also use MVVMLight.
My current solution:
I have a window and the window contains custom user controls (they represent every page of the wizard).
Both the window and the user controls share the same view model
When you click back/next the view model handles which user control that should be visible
The problem with this one is that I don't like the shared view model. I have a shared view model because all pages configure different things on the same object and it's easier to follow. But at the same time thew view model contains a lot of things that each individuell user control doesn't need (for example only one page need methods to add/edit filters). It also makes it hard to re-user the user control later if I want them for something else than the wizard.
So should I instead create diffrent view models for the window and each user control and send messages between the view models with MVVMLights MessengerInstance? I feel that's cleaner but as a reader it's maybe harder to follow (something I feel in general when I sending messages around)?
With messenger it would be a workflow like this:
User enter all the information on a "page"
User click on next (that belongs to the window)
The windows view model have to send a message to the user control to check if all the data is valid
The user control check the data and have to send back if it's valid or not. If it's valid tell the next page to get visible, if not show error message.
So it would be a lot of messages back and forth that I don't need with the shared view model solution.
Or is there a better solution that I should do?
I would expect that the answers you receive here are primarily opinion based, but here goes anyway.
Currently, your view model has more than one responsibility, and therefore, more than one reason to change. It's certainly a good idea to split up your view models into smaller, more manageable classes. This may appear to reduce readability, however I would disagree. The idea of ensuring that classes only have one responsibility keeps things simple and promotes re-use.
That being said, your main view model will most likely hold references to many other child view models, but this isn't the end of the world, in fact, it's a good thing. The parent-child relationship between your view models is much like the parent-child relationship in your views. For example, a Window contains many UserControls, there's nothing wrong with mimicking this relationship with the view models.
Now, there are of course a few ways to communicate between view models. I personally prefer to use events, where a child view model raises an event that the parent view model subscribes to. Pretty simple, really. Although there is some degree of coupling in this scenario, you could of course abstract your classes away into interfaces and use dependency injection to inject them into the parent view model. Using events is down to personal preference, however MVVMLight has quite a nice MessengerInstance that decouples view models even further.
So. My suggestion:
Work out the responsibilities of your view model.
Split up the massive view model into smaller view models (based on the responsibilities).
Create a parent-child relationships between view models. Your view will in fact point you in the right direction in terms of the relationships.
I'm currently working on my first MVVM project and I need some feedback on the ViewModels... well, I should actually miss out the plural 's': I have one big fat large MainViewModel right now.
I'm building a survey-analyzis-tool: There is a list of surveys from which users can pick one and a result page where infos for the selected survey are displayed. There is, e.g., the property "SelectedSurvey" which binds the user's selected survey. This property is needed for the result page as well.
Is one large ViewModel maybe not so bad after all?
You can use something like the MVVM Light Messenger to exchange data between ViewModels:
MVVM Light Messenger - Sending and Registering Objects
Generally speaking I try to stick to a 1:1 ratio of Views to ViewModels. If your View requires a truly huge ViewModel then perhaps you could eliminate some clutter by refactoring supporting methods into their own classes.
I am using ViewModels with asp.net MVC3. One of the thing I am curious about is, suppose I have an entity named Customers and it has Add, Edit, Delete screens. Assume that they all have different properties requirements.
For eg. Add may have address field but the edit screen may not have edit screen, delete may only use customer name more than anything else.
My question is, how do you create ViewModels for this? Do you go with the approach of shared ViewModels between add, edit and delete i.e a single viewmodel class that handles all for you or do you prefer to create viewmodels classes / page?
Advantage with shared viewmodel is it reduces development time and we can reuse classes. But big problem with this is that if you are using tool like Automapper you may expected results for different screens.
Disadvantage with one viewmodel/page is that it increases development time. Which way should I go?
My approach to view models is to use shared view models until the requirements (the data transported) to the view is different. That means I'm using a shared view model for example for CreateAddress and EditAddress in case all data transported to the view is the same. In case an additional field needs to be displayed in the view for example in the CreateAddress view I'm refactoring my view models and using different view models for CreateAddress and EditAddress.
For example for DeleteAddress I'd use a distinct view model from start because I know that the data displayed in the DeleteAddress view is almost never the same as in Create/EditAddress.
Another approach is to use dynamic view models, since view models should/must not implement business logic and act as DTOs between controller and view this approach has some benefits (No need to create logic free, throw away DTOs).
It depends upon situation. if you have similar requirements for different screens (validation, properties to render etc.) you can use the viewmodel across different views. If there is difference of one or two properties, i would still use the same viewmodel and where these properties are not needed i will put them in hidden inputs so they travel back with the form post not allowing unwanted results. Hidden fields, as all know, can be tweaked and its upon developer to decide if it is safe to use hidden fields. However, if i have different validation requirements for two screens then i definitely have to go with viewmodel/page approach. You can mix both approaches according to requirements as they say "there is no best way of doing things"
All fields that exists in a model can be changed. It doesn't matter if they are hidden or not. All the user has to do is to inspect your pages and try to figure out what fields exist in the model.
Then he can add those fields (for instance with Chrome Dev Tools) to make changes to them.
The safest way to get rid of that problem is to just have models that only have the fields that are allowed to be changed.
That said, go ahead and use the same model if all fields in the model should be allowed to be changed by all users. (And simply do not show the fields that should not be modified)