I am creating a program which utilizes MVP architecture. Please tell me which is the best place to write the validation. Someone told me that the code in presenter should only contains logic to handle events raised from the GUI and format values collected from the model so that view can display values without any overhear. Is this correct?
Related
I am having a hard time understanding how MVVM is used in case of more complex applications. All the examples I can find are extremely basic Apps.
Let's say I have a "Package Delivery" application. To perform a delivery I have to do 3 steps:
Scan the package
Enter any damages or problems with the package
Let the recipient sign on the device
All this information gets validated on the device and then sent to the backend.
In MVC I would implement this like this:
The DeliveryController handles all of the logic. This includes navigation between pages, fetching of API data and validating all of the data once it is all collected.
The controller acts as the "Connection" between the Views and collects all the information and brings it together.
But how would this be done in MVVM? Where would all the data be brought together? Most implementations of MVVM I can find do something like this:
In this, the data entered in each View would have to be passed to the next ViewModel until the end of the chain is reached. At that point the SignatureViewModel would do the validation and make the API call. That seems very weird and like it would get very confusing, since data would just be "passed through" multiple ViewModels just to have it at the end of the chain.
Another option I see would be that each ViewModel handles it's own data:
Here for instance the DamagesViewModel would validate and send the data it's own View handles. The big issue with this is that data does not get sent as a whole. Also there can not be any validation of the entire data before it is sent.
My last idea would look like this:
This adds a DeliveryViewModel that essentials acts like the DeliveryController does in MVC. It would handle which ViewModel to navigate to next, handle what API calls to make and validate all the data once it is entered.
To me (as someone who has mostly used MVC) this last options seems most sensible. But I also feel like it might miss the point of MVVM.
How is this usually done in MVVM? I would really appreciate any pointers. Links to articles that explain this well are much appreciated.
Also if anyone knows of any publicly available repositories or projects that have this kind of pattern in them, I would love to see them.
Even when using MVVM I still use some form of a controller and consider ViewModels as basically transformation of data to facilitate the view.
So for me there is still a service or controller layer that completely separates the middle and back end tier from the rest of the architecture.
View models come into play depending on the consumer/app - fetches data from the service tier, transforming the data, validating etc for the purpose of a consumer/app/etc.
I have struggled quite a bit with the same thing. Especially since I’ve used MVC quite a lot.
I think the most important thing to consider is that MVVM is not meant to solve exactly the same things as MVC. You can still implement a controller outside of this pattern to complement it. It also changes quite a lot the general design of the application.
One mean to do it that I have used is to implement the controller as a singleton that can be shared between VewModels. This controller can per example be injected into the ViewModels using dependency injection.
Viewmodels could then for exemple subscribe to events coming from the controller to update.
But this is one way to solve this problem among others.
MVVM is a way to organize code. It’s one way to separate your user interface from your logic.
I have found a blog where you can have a look where MVVM architecture is described perfectly.Though here writer demonstrates MVVM for windows form app but at least you can get some idea about architectural design of MVVM.
https://scottlilly.com/c-design-patterns-mvvm-model-view-viewmodel/
Also please have a look into this repo.
https://github.com/MarkWithall/worlds-simplest-csharp-wpf-mvvm-example
I'm pretty new to WPF so I've been struggling with some basic concepts.
My application consists out of a main window containing various tabs. The first tab is used to add files, activating the other tabs which operate on the given files. For simplicity, let's call the latter "DataTabs".
I'm not sure about how to correctly communicate between the tabs. Currently, the FileInputTab uses a designated ICommand to do the following: Read the data, create a view model for the DataTab, and raise a "ViewModelReadyEvent" using the FileInputTab's view.
This event then bubbles up to the MainWindow, which activates the DataTabs and passes the created ViewModel on to them.
Now, two things I'm struggling with.
Populating the view model
Is it a better approach to populate the view model for the DataTabs inside their corresponding views, rather than from the FileInputTab that actually has nothing to do with it? This way, I could correctly establish a reference between the two, but I would have to perform the population separatly for every DataTab. Any thoughts?
Communication between "sibling" views
It doesn't feel right to let the event bubble up all the way to the MainWindow to let it orchestrate all inter-view communcation. I looked into RoutingStrategies, but I can't find any way to directly communicate between "sibling" views. I would like to raise an event in the FileInputTab and directly act on it in the DataTabs, without any intermediate.
Any thoughts, comments or book recommendations by WPF experts would be appreciated. Thanks in advance.
Using MVVM you could introduce a ViewModel for every tab. Then you could write a Service for the communication between the ViewModels. It is quite easy if you use the Messenger Pattern. One ViewModel sends a message to the Service and the Service leads it forward to the other ViewModel. The Service would also do the work, so your ViewModel would not have any business logic.
MVVM Light helps you a lot with the MVVM pattern.
You can use IEventAggregator to communicate between ViewModels.
I'm designing a C# / WPF application, and trying to adhere to MVVM (but I don't mind taking shortcuts, as I'm quite a beginner).
I have a ViewModel and several Models. In the View there is a TextBox that is meant to log messages about what is happening in the models. The text of the TextBox is already bound to a string property in my ViewModel, but how can I give my Models the ability to append text to that TextBox without breaking the MVVM concept too much?
I was thinking about using Trace and a Trace listener for my TextBox. Is there any other (simple) way?
Thanks
If you put functionality like networking in your model, it's not a model anymore. It will have to many responsibilities and will violate the Single Responsibility Principle (SRP).
Reduce your models to contain only logic tied with the model class itself. Move functionality like networking into service classes.
Update is result of user action in the same ViewModel
Call service classes from ViewModel (i.e. in commands representing user actions) and if the call is successful, get the updated value.
Update action happens in another ViewModel or somewhere else (timer/polling)
If the sync happens somewhere else, use EventAggregator. Your service can fire an event/message, your ViewModel will subscribe to it. When receiving this event, update your ViewModel and rise PropertyChanged.
I am creating a Windows Forms application that reads various tables from a database into a DataSet in order to display said tables in multiple DataGridViews. Rather than putting all my code in the code-behind file, I have started doing some research on different design patterns, and have found many articles/threads with the consensus that MVP is the best option for WinForms.
After doing a few tutorials, and starting to organize my code using the MVP pattern; I have placed my DataSet in what would be the Model, most of the logic in the Presenter, and everything else in the View.
My question is: where should I place the validation of user input? I do not want the user to be able to enter invalid values into the DataGridViews, and if they happen to do so, I would like to let them know the row/cell that has the error. Previously, I would handle the RowValidating event and check the row and cells of the DataGridView for any errors, and then display a message accordingly, but this seems to not fit within the MVP pattern.
Should I leave the validation in the view, or should it be moved elsewhere?
IMHO you should keep the view (the form) as simple as possible. You can indeed subscribe for the RowValidating event and call the presenter (presenter.ValidateRow(...)) from there and pass to it the info and let it handle the validation. The presenter on his turn can ask the model for some info if the validation logic happens to be complex and has to go all the way down (to the DB for example). It is the presenter's responsibility for how to handle the errors. When the validation process completes it's the presenter's job to call a method or set a property on the view in order to display failure or success. Remember that your view is just a "window" to the state of your business logic (objects). Ask yourself the question "Is my program going to work if I swap this specific view with another implementing the same interface but not written by me?".
You may want to take a look at this http://msdn.microsoft.com/en-us/magazine/ee336019.aspx article for further clarification on MVP pattern.
I have seen couple of discussion on where to write UI validation in MVP.
There is quiet confusion over this as suggestion on keeping view and presenter. But displaying message box in presenter does not looks very good similarly putting logic in view restrict us from unit testing.
One more aspect is Sharing validation across the application. My thinking is to keep the UI validation in UI model by passing presenter. Even we could reuse this and also it reduces the size and complexity of the presenter. Handling in UI model looks more object oriented.
Is it right approach? Can you guide me on right direction?
The pattern is typically that all functionality should go in the presenter, that way it's reusable and testable. That doesn't mean you can't create some sort of validation display control to display them nicely.
Have a look at the way Silverlight RIA services does it.