Currently i am working on a project using prism where one of our modules has a viewmodel with 3000 lines of code!!!. really I would split this class to little pieces (some time is hard to read the code inside of this viewmodel)
Actually the code of the viewmodel has more less 30 properties related with commands and i think there it's good place to start.. (some idea how can i move these commands to other class?)
any ideas?
Thank you!
There are a few things you can do, firstly how much of the code should be in the view model, and how much of it should be in the model itself?
Secondly, can any of the code be part of services that the view model takes as a dependency?
Thirdly, you might want to consider a conventions based MVVM framework such as Caliburn.Micro which will allow you to use actions instead of WPF commanding, which means considerably less boilerplate code binding up verbs on your view model with events on your view, as well as other advantages.
Related
Im currently working on a project where I want to the user to be able to chose between two layouts (list and grid) at runtime. I was searching for examples in the UI5 documentation (Sample Apps) and on GitHub, I did not find examples for how to to this or best practice examples. So I thought about how I could achieve this behaviour and had multiple ideas, but somehow none of them feels like doing this would be best practice.
Idea 1 - Destroy the "old" controls and generate the new controls inside the Controller
My first idea was to destory the controls I do not longer need. For example if the user wants to switch to the grid layout, the list and every control related it to it gets destoyed. In the controller the needed controls for the grid are created and then rendered in the view. In my eyes this would mix up view and controller logic inside the controller and does not feel like best practice
Idea 2 - Create two views and switch between them
My second idea was to create two views, each for the layout I need and switch between them. This would mean a lot of code replication in both the controller and the view. Does not feel like this would be the right way.
So I would be glad if you have own experience on this or if there is really something like a best practice for such a behaviour.
Thank you and kind regards!
I would say, idea 2 because of the following reasons:
It is best practice to work according to the MVC methodology which means separating logic, view and data. Since the controls define your view it is best to instantiate your controls in the files that are meant for it (the XML Views).
Performance: Destroying all controls means that if the user decides to switch between views, the controls have to be re-instantiated by the controller every time. This is, even though you probably won't notice it, not performant.
You don't need code replication: The argument of code replication is not necessarily true. If you can execute the same actions in the list and grid-view, it should be enough to just link the controller to both views and in that case you'll hardly have to replicate any code. Just make sure that you split your logic in enough functions. That way you might need to write some extra public functions to handle events, but not much more.
I have been using the MVVM Light Toolkit to help learn the MVVM pattern. However, I have not been able to solve the problem of usercontrols within controls scenario.
For example, in a Timesheet application, lets say we have a control called NewUnitOfWork. When it first loads, a panel with a ListBox with a list of projects is loaded as the Content of the NewUnitOfWork. The user clicks on one. A new panel is swapped in with a ListBox containing the possible tasks for that project. A task is selected and a new panel is loaded which will contain controls to input data for the chosen task of the chosen project.
So, we have the selected item in one usercontrol being passed to the other two user controls, which are, in turn swapped in as the Content of the NewUnitOfWork control (or window).
If each control has its own ViewModel, we need to pass the selected value from one ViewModel to the next etc.
I have got it working in a single user situation using global variables (via a "service"). However, there are concurrency issues with that and it is not a good solution. It's sub-par.
I have seen many times the suggestion on this forum to have on ViewModel as a member of another ViewModel. Whilst this solves the problem at hand, I believe it is a violation of the MVVM pattern. Another ViewModel is not UI-related functionality that the ViewModel shoule be directly.
So. Has anyone found a clean MVVM-complying way to do this sort of thing?
Cheers
Please always keep in mind that MVVM is just a pattern and it is designed to help you separate your UI and logic. Do not be afraid to “violate the pattern” if it helps to increase testability or maintainability of the application.
Having a master ViewModel with several child ViewModels is very handy if you have a complex UI. The main ViewModel may be responsible for handling the top level UI controls and for coordination of the child VMs, while other ViewModels are responsible for communication with the sub regions of your UI.
Moreover, if you have a really complex UI with the multiple nesting UI layers, you can implement an infrastructure to automatically cascade all the events from master to child VMs.
And of cause, you may try to use one of the more advanced MVVM frameworks. For example Catel implements pretty comprehensive model to resolve such situations with nested VMs.
I don't see a problem with ViewModels referencing other ViewModels (based on my experience with TreeViews). Have a look at any article about TreeView and MVVM. You will see that each node is a ViewModel, that references a collection of child nodes, which are ViewModels. Trying to do that without VM-VM references would be a nightmare.
Josh Smith
http://www.codeproject.com/KB/WPF/TreeViewWithViewModel.aspx
I have been using the following setup:
A 'master' VM with a 'collection' VM and a 'details' VM as nested properties.
The master VM is tied to a View that is used as a master-detail form. This master-detail View is composed from two other Views.
I find it a very neat setup because it allows me to put search criteria in the master View(Model) and keeps the other View(Model)s clean.
I can't see how this would break the pattern.
Do you create a Viewcontroller per view screen? or should you share a viewcontrollers? (ie in the example below Should there be 3 controllers or just 1 controller?)
Example
Screens are related
Screen1 (input information),
Screen2 (Review and confirm Information),
Screen3 (thank you / status response).
You should code according to the MVC paradigm. Parcel out your code and separate it based on overrarching function. Here is a high level overview of MVC
(Data) Model: contains all of your app data, objects that are passed around and used to populate the views
View: everything that is some sort of visual output
Controller: Classes that make the models and views work together.
What this is saying, in iPhone development parlance, is don't just jam a bunch of code into your UIViewController subclass. If you want to change the way part of the system works, having one huge class with a ton of code in it is a lot harder to edit and fix, than several smaller classes with a specialized use.
To answer your question, you should most definitely use one controller for each view function, but going beyond that, you should create specialized classes that take the inputs and manipulate that data, create specialized classes that then use the data to send it back to the user in an output.
Don't put all of your code into one class. It might work, but if you ever need to tweak it, or, just like when the iPad came out, it has to be adapted to use on another platform, it will be easier to manage if you only have to change something small to make it work
In your case you definitely don't need separate controllers. In fact you don't even need separate views. You can create a single view to take information, process it in the same controller and show the result in a UIAlertView.
I'm a little confused about MVVM.
I understand the concept and can see the advantages. My problem is: does the ViewModel pass data directly from the model.
For example, let's say I have a "User" model with a findByName() method. The ViewModel would call this in order to pass
the relevant user details to the view.
The model would likely retrun a set of "User" objects each which has properties such as name, email address etc and may also have methods.
My question is, should the ViewModel return the set of User objects to the view, or return a restructured version of this which
contains only what the view needs?
As I understand it, the "User" object in this case is part of the model layer and in MVVM the View should be dependant only on the ViewModel.
My issue with this is the ammount of seemingly redundant binding logic required in the ViewModel that would be created to restructure the output.
Passing the set of User objects directly to the View (via the ViewModel) would be far simpler.
There's a little bit of redundancy, sure. However, if you implement MVVM by presenting the objects, you get to
format the model information for the view without polluting the model with presentation logic
notify the view when anything changes
use WPF's validation (if you're using WPF)
run acceptance tests from the VM level rather than the GUI if you want to
abstract your presentation away from any changes to the model.
That last one's important. Mostly presentation bindings nowadays are dynamic and fail silently - web pages, WPF, you name it. That means that if someone decides to rename something on the model, it will suddenly break in your GUI and you won't know.
By putting a VM between your Model and View you buffer yourself from changes like this.
If you want to go ahead and get something working with the Users as they are, I say go for it - it'll help you get fast feedback on your GUI. However, the first time those User objects don't do exactly what the View needs, or you need to notify the View of a change, or you find yourself polluting the model, or something in the binding breaks, maybe that's a good time to move to MVVM.
Doesn't that just move the break to the ViewModels which are using the model? You'd still need to go through and update all of those.
If I renamed something (e.g. changed "surname" to "lastname") I'd expect things to break. I don't see how adding the binding in the VM layer fixes that.
I'm a beginner with Eclipse RCP and I'm trying to build an application for myself to give it a go. I'm confused about how one actually goes about handling model objects. None of the examples I can find deal with the problem I'm having, so I suspect I'm going about it the wrong way.
Say I need to initialise the application with a class that holds authenticated user info. I used my WorkbenchWindowAdvisor (wrong place?) to perform some initialisation (e.g. authentication) to decide what view to show. Once that's done, a view is shown. Now, that view also needs access to the user info I had earlier retrieved/produced.
The question is, how is that view supposed to get that data? The view is wired up in the plugin.xml. I don't see any way I can give the data to the view. So I assume the view has to retrieve it somehow. But what's the proper place for it to retrieve it from? I thought of putting static variables in the IApplication implementation, but that felt wrong. Any advice or pointers much appreciated. Thanks.
The problem you are facing here is in my opinion not RCP related. Its more an architectural problem. Your view is wired with business logicand!
The solution can be done by two (common) design-patterns:
Model-View-Controler (MVC)
Model-View-Presenter (MVP)
You can find plenty information about this in the web. I am going to point a possible solution for your particular problem using MVP.
You will need to create several projects. One is of course an RCP plugin, lets call it rcp.view. Now you create another one, which doesnt make UI contributions (only org.eclipse.core.runtime to start with) and call it rcp.presenter. To simplify things, this plugin will also be the model for now.
Next steps:
Add the rcp.presenter to the
dependencies of rcp.view (its
important that the presenter has no
reference to the view)
Export all packages that you are
going to create in the rcp.presenter
so they are visible
In rcp.presenter create an interface
IPerspective that has some methods
like (showLogiDialog(), showAdministratorViews(User user), showStandardViews(User user))
Create a class PerspectivePresenter that takes IPerspective in the constructor and saves it in an attribute
In rcp.view go to your Perspective, implement your interface IPerspective, and in the constructor create a new reference presenter = new PerspectivePresenter(this)
call presenter.load() and implenent
this in the presenter maybe like this
code:
public void load()
{
User user = view.showLoginDialog(); // returns a user with the provided name/pw
user.login(); // login to system/database
if(user.isAdministrator())
view.showAdministratorViews(user);
else
view.showStandardViews(user);
}
As you can see, the view just creates a reference to the presenter, which is responsible for all the business logic, and the presenter tells the view what to display. So in your Perspective you implement those interface functions and in each one you can set up your Perspective in a different way.
For each View it goes in the same way, you will need a presenter for the view which performs operations and tells the view (using the interface) what to display and passing down the final data. The view doesnt care about the logic. This is also very usefull when using JFace-Databindings (then only bound data is passed to the view).
For example, the WorkbenchWindowAdisor will just create everything that is needed in the application. Other views, perspectives, then can enable/disable menus and so on depending on the data they got (like when isAdministrator you might want to enable an special adminMenu).
I know this is quite a heavy approach, but the Eclipse RCP is designed for big (as the name says rich) applications. So you should spend some time in the right architecture. My first RCP app was like you described...I never knew where to store things and how to handle all the references. At my work I learned about MVP (and I am still learning). It takes a while to understand the concept but its worth it.
You might want to look at my second post at this question to get another idea on how you could structure your plugins.