I need some guidance with the interaction of different components in MVP.
For example, I have an application to manage data in a hospital. So let's assume the UI has a patient editor. Now as far as I understand MVP, I would create a PatientPresenter with a PatientView and a PatientModel. Now the PatientView would show the user interface and when it changes delegate it to PatientPresenter which would then update PatientModel. When the model changes, should it inform the presenter or directly inform the view which then updates the view?
Now let us assume there's a parent component, a PatientManager which shows an overview of patients, allows to search the patients and so on. Now I could do another triad for this component, but how would it interact with the PatientModel/View/Presenter?
It would make sense to me if the PatientManagerMode would have several PatientModels and it would also make sense to me if the PatientManagerView holds an instance of the PatientView as a childcontrol, however why should the PatientManagerPresenter hold an instance of the PatientPresenter? And if it shouldn't, who should?
So what exactly should happen if I double click something in the PatientManager so that I can edit the patient?
When the model changes, should it
inform the presenter or directly
inform the view which then updates the
view?
The model should inform the presenter which then updates the view.
Now let us assume there's a parent
component, a PatientManager which
shows an overview of patients, ... but
how would it interact with the
PatientModel/View/Presenter?
I would consider them as subviews of a larger UI that deals with managing Patients. In this case the Presenter would handle both. Taking responsibility for filling out the Patient Manager and responding to searches. Then when the operator selects a patient the view passes that to the presents. Then when the patient details are brought out the presents retrieves the data from the model and fill out the patient details.
The way I would layer it is like this
View Assembly/EXE/Package
Presenter Assembly/DLL/Package
Commands Assembly/DLL/Package
Presenter Manager Assembly/DLL/Package
Model Assembly/DLL/Package
The View would implement the view interfaces found in the Presenter say IPatientManagerView and IPatientView and registers themselves with the Presenter. The implementations would use the Presenter Interfaces exposed through Presenter Manager. For example IPatientManager and IPatient
The Presenters would implement the Presenter Interface found in the Presenter Manager and register themselves in the Presenter Manager. It could be one class that implements both IPatientManager and IPatient or two. When it needs to perform an action either UI related or Model related it executes a command found in Commands. The command would use the Model and/or the Presenter Interfaces to perform the action.
To bring up a patient would look something like this.
You have a dialog that implements IPatientManagerView and is registered with a class that implements IPatientManager.
User clicks Search
Search calls the Search Method of
IPatientManager
The class implement IPatientManager
uses IPatientManagerView to retrieves
the search parameters.
Then setups up and execute the Search
Command which retrieves a list of
patient.
The Search Command calls ListPatients
on IPatientManager
The class implementing
IPatientManager uses a method
IPatientManagerView to clear and fill
out the list of patient.
User Double Clicks on a Patient
The Dialog implement
IPatientManagerView will call the
class implementing IPatientManager
indicating that a specific patient is
to be view.
The class implementing
IPatientManager retrieves the
information about the patient needed
to view from the dialog implementing
IPatientManageView
IPatientManager then setups and
executes a command to view the
Patient.
The command retrieves all the
patient's information from the Model
and calls the ViewPatient Method on
the class implementing
IPatientManager
IPatientManager then retrieves the
class implementing IPatient.
Passes the patient information to
IPatients and tells it to display
itself. IPatient then retrieves the
IPatientView that is registered with
it.
Fill it out with with the patient
data using IPatientView and then
tells IPatientView to display itself.
With this scheme you can radically change the UI by changing what implements the various view interfaces. You can also easily right automated test by creating dummy classes that implement the View interfaces. Plus for future maintenance every interaction is explicitly documented through the interfaces.
Related
How to create a TextField is explained very well in a tutorial. But I am wondering how to store and retrieve the entered strings in a persistant way, that survives application termination and restart (something like a Bash history).
I will try to give you a very briefly answer
You need
a viewmodel class
a repository class
a database (room database is ideal)
an entity data class
a dao class
You should find more info about room database from jetpack libraries.
Of course are uncounted ways to implement this feature but it is in general the following way recommended.
You capture from your view the query string, may on submit.
In viewmodel you implement a method captureSearchQuery(query: String)
Also in viewmodel you implement a method for example retrieveSearchHistory() : Flow<List>
The repository class is your single source of true, is the layer between the data layer and the view layer, you implement also this two methods you need, captureSearchQuery and retrieveSearchHistory. In repository class you can may transform your data, for example is a good practice to have a separate data model for the data you display on the view from your room entity. There you can do this transformation for exmaple.
Now you have setup your room database you can insert and get the data you need.
The data should go this way:
View -> Viewmodel -> Repository -> Room database
View <- Viewmodel <- Repository <- Room database
The layer should never communicate otherway, (clean architecture) for example:
View -> Room database.
The above is my simplest explanation, I hope I help you
I'm just starting to learn the MVC design pattern, and I was wondering where should my SQL code go.
For example, lets say I have a register form structure that looks like this
type Form struct {
Username string
Password string
}
I assume that the form structure is part of the model, so I have some function that goes with the form that after a user submits the form, the data gets put into the database, so my function would look something like this
func (f *Form) registerUser() {
// SQL code goes here
}
Is this the best way of doing it? I have been searching around for open source Golang web apps that utilizes the MVC pattern, but I have not be able to find one which I completely understand.
In model-view-controller pattern...
Model is for entities all your classes represent real world objects.
View is the forms and all the graphic things user can see and interact with.
Controller is for controller classes, is all the logic of the program, for the sql code as you said you can implement a dao pattern and have all the sql code in the controller package and the database class in the entities package(i leave it in the Controller class).
I assume that the form structure is part of the model, so I have some function that goes with the form that after a user submits the form, the data gets put into the database, so my function would look something like this
Another use of Model in MVC application architecture is to store reusable code. So, yes, you can store the form in Model (for example, if you reuse it multiple in views) but this makes less sense than storing form in a View and reuse it later on.
The execution backtrace would be something like
Controller processes the request - personally, I do the business logic here and also (if necessary) invoke ...
Model that handles all the data retrieval from DBMS, validation, etc. and returns processed data to Controller and ...
The View is then displayed with the respective parameters (user data, template, validator result, etc.).
User fills in the form and submits the input to Controller and ...
GOTO 1. point
Just wondering really if there's a consensus on the 'right' way to do this, for MVVM, DDD, and other philosophies . . .
So I've got a login screen, represented by a ViewModel, LoginViewModel. It can take a name and password. It also takes in through dependency injection a LoginService, that implements the logic of taking the username and password, and retrieving the Employee object.
My question is what's the 'right' way to get this information to the next view model? Let's say it's AccountSettings, which needs to know about the logged in employee. How do we encapsulate that? I've got an AccountSettingsViewModel, but should it require
a) An instance of the LoginViewModel?
b) An instance of the LoginService, which keeps a reference to the logged in employee
c) A shared object or field on a global object, like App or something?
Thanks in advance!
Personally all my view models in DDD or otherwise are simple data containers, used to restrict the data that gets sent from the application to the UI/view. I might include some code in my view models that's specific to transforming data for that view. I also consider my view models to be coupled to my views (I only mention this because I've seen 2 teams put them in their own separate project/assembly away from the views!).
If I have anything copying data, or performing actions to get the data needed for the view model, this would live in either my domain model or my application layer, probably in a service. I wouldn't ever inject a service into a view model.
I'm redesigning an old VB6 application into VB.net and there is one thing I'm not sure on the best way to do.
In the VB6 application whenever we created a new instance of a component, we would pass in the user details (user name and the like) so we new who was performing the tasks. However, no that I'm redesigning I've created some nice class designs, but I'm having to add in user details into every class and it just looks wrong.
Is there a VB.net way of doing this so my classes can just have class specific details? Some way so that if my classes need to know who is performing a task, they can get the information themselves, rather than having it passed in whenever the objects are created?
You could put the details of the current user in a class that is accessible by all class instances of your application.
One place you could consider putting it is in the MyApplication class. You could also create a module and place it there.
Could you wrap the current user details into an object, and pass the object when you create the others? They would just keep a reference, and delegate to the user object for user-specific stuff.
That seems like the obvious way?
I've got this Silverlight Prism application that is using MVVM. The model calls a WCF service and a list of data is returned.
The ViewModel is bound to the View, so the ViewModel should have a List property.
Were should I keep data returned by a WCF service in MVVM?
Should the List property be calling into the Model using its getter? Where the model has a ReturnListOfData() method that returns the data stored in the model.
Or does the ViewModel stores the data after the Model is done with calling the server?
This is a follow up on Where to put the calls to WCF or other webservices in MVVM?
Generally if I need to keep the Model objects around (I consider most things coming back from a WCF service a Model object) I will store it in my ViewModel in a "Model" property.
I've seen people go so far as to create a standard Model property on their base ViewModel type, like this (I don't do this, but it's nice):
public class ViewModel<ModelType> : INotifyPropertyChanged ...
{
//Model Property
public ModelType Model
{
...
}
}
It's really up to you. Keeping them as close to their related ViewModels is probably the thing to take away here.
It really depends on other aspects of your application. E.g. how's the data returned by ReturnListOfData() used? Are there other components interested in it? Does user update elements in the list? Can it create new elements that he'll want to save later? etc.
In the simplest case you'd just have a List property exposed by your viewmodel to view, and you'd reset that list to whatever ReturnListOfData() returned. It will probably work for a case when user simply performs a search, doesn't do anything to the data later on, and there's only one view that is interested in that data.
But suppose a user wants to be able to modify elements of that list. Clearly, you'll have to somehow track the changes in that original list, so then when user clicks save (or cancel), you'd send to the server only elements that were changed (or added) or restore the original elements if user clicks cancel. In this case you'd need a Model object, that would keep the original data, so then your viewmodel contains only its copy.