Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>You should be doing one presenter per one control because of:</p> <ul> <li>that would allow you to have <strong>focused unit tests</strong> tackling only that control </li> <li><strong>increased maintainability</strong> due to the fact you won’t need to support gigantic presenter containing union of presentation logic of all controls</li> <li>that would <strong>prevent redundancy</strong> in cases of having same control on multiple pages</li> <li><strong>Increases SRP</strong> by having controls focusing on their specific logic while the page performs container specific roles:</li> </ul> <p>There are two problems usually mentioned related to the decision “presenter per control”:</p> <ul> <li><strong>Shared context</strong> is problem where due to the fact that all of the controls are just showing different pieces of the same page data context, that situation may look like a problematic use case leading to a lot of data retrieval redundant code in every of the controls. That is easily solvable through dependency injection where page (or controller) performs single data retrieval and then inject the data context object into every of the presenters\views (usually implementing some interface enabling that). In case of MV-VM pattern (Silverlight, WPF) same effect can be achieved through data bounding where the page would set its DataContext which would then be used from views itself</li> <li><strong>Communication between views</strong> on the same page is second problem which is easily solvable using couple of approaches:</li> <li>Controls are publishing <strong>events</strong> to which page subscribes and then makes direct calls to appropriate methods in other controls (page is container to all controls meaning it is aware of all of their members) </li> <li><strong>Observer</strong> design pattern </li> <li><strong>Event aggregator</strong> pattern</li> </ul> <p>In each one of this approaches controls are communicating with each other without being aware of each other</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload