Q) I believe all UI modification (such as changing the text forecolor when a threshold is met) needs to be done in the view level as the model does not have any direct contact with controller. Is this correct?
A) Yes. If view is directly retrieving the new data from the Model.
No. If view is seeking controllers' help to query the new data. In this case, the controller can format the data and send it to the view.
Q) I see a dotted line connecting the model to view indicating an 'indirect' relationship. Can you please explain what is that indirect relationship means?
The model does not know the view, but the view knows the model.
Q) I’ve seen objects like interactors, commands, selections in some MVP explanations. When should I use that?
A) These objects existed in Mike Potel’s MVP in such age when the user controls and GUI were not developed like today. In current windows world, we can very well execute a MVP pattern without the objects mentioned in the question.
Please keep in mind that design patterns are loose guidelines which help you to solve common problems. It is not necessary to strictly follow a design pattern to the core. You may tweak a design pattern as per your need.
Q) What is the benefit of having a presenter? - Why can't the view talk to the model immediately?
A) The basic idea behind the MVP pattern is separation of concerns. This improves testability and mock objects can be introduced to test the domain part. Besides that, we can change the views which can represent the model data differently.
Q) Where should I write validation in MVC/MVP architecture?
A) The basic control validations like empty field validation should be done at view level. Anything concerning the database should be written inside the model as
A) Yes. If view is directly retrieving the new data from the Model.
No. If view is seeking controllers' help to query the new data. In this case, the controller can format the data and send it to the view.
Q) I see a dotted line connecting the model to view indicating an 'indirect' relationship. Can you please explain what is that indirect relationship means?
The model does not know the view, but the view knows the model.
Q) I’ve seen objects like interactors, commands, selections in some MVP explanations. When should I use that?
A) These objects existed in Mike Potel’s MVP in such age when the user controls and GUI were not developed like today. In current windows world, we can very well execute a MVP pattern without the objects mentioned in the question.
Please keep in mind that design patterns are loose guidelines which help you to solve common problems. It is not necessary to strictly follow a design pattern to the core. You may tweak a design pattern as per your need.
Q) What is the benefit of having a presenter? - Why can't the view talk to the model immediately?
A) The basic idea behind the MVP pattern is separation of concerns. This improves testability and mock objects can be introduced to test the domain part. Besides that, we can change the views which can represent the model data differently.
Q) Where should I write validation in MVC/MVP architecture?
A) The basic control validations like empty field validation should be done at view level. Anything concerning the database should be written inside the model as
public methods. This method will be consumed by the Controller to do the validation before the data reaches the Model. Difference Table
No comments:
Post a Comment