views:

122

answers:

1

According to Presentation Model notes by Martin Fowler and also on MSDN documentation about Presentation Model, it is explained that the Presentation Model Class should be unaware of the UI class and similarly Business Model Class should be unaware of the Presentation Model class.

The UI should databind extensively to the Presentation Model, the Presentation Model in turn will co-ordinate with one or more Domain/Business Model objects to get the job done. The Presentation Model basically presents the Domain Model data in a way to facilitate maximum data binding in UI, allowing the UI take as less decisions as possible and thus increase testability of Presentation behaviours. This also makes the presentation model class generic, i.e. agnostic of any particular UI technology.

Now, consider there is a List form (say CustomerList) and there is another Root form (say Customer) and there is a Use Case of allowing to Edit a Customer from the CustomerList form on a button click.

For simplicity of discussion, consider that some actions took place when Customer List is opened from menu (i.e. Customer menu clicked) and the Customer List has been shown from the Menu click event.

Now as per the above Use Case, I need to open the Customer Root UI (single Customer) from the Customer List. How do I do that?

  1. Build necessary objects (BusinessModel, PresentationModel, UI) in click event of Edit button and call CustomerEdit UI from there?

  2. Build the CustomerEdit UI from Presentation Model Class and show UI from presentation model? this can be done in any of the two ways below - a. Create objects in the following sequence DomainModel->PresentationModel-UIForm b. Use Unity.Resolve(); Either ways, Presentation Model is violated as the P model now has to the refer the concrete UI assembly, where CustomerEdit is located. Also the P Model has to refer and use a WinForm directly making it less UI technology agnostic.

Even though the violations are in theory and can be ignored, I would still seek the community's opinion about whether I am going wrong direction. Please suggest if there's a better way to call the Child Form from the List (Parent) Form.

  • Rajarshi
A: 

Your aim is usually the loose coupling between different parts the system for that sake of easier maintainability. This means that your model, for example, should not know that exact types it communicates with. It should know only about required interfaces.

There is nothing bad or strange when your model references something in your UI or in business logic layer, as long as it operates with interfaces instead of specific types.

newtover
When you said "Model references something in your UI" did you mean Domain Model or Presentation Model? If you say Domain Model, then I would disagree as it violates a stronger discipline i.e. "Separation of Concerns". If you say Presentation Model then I kind of agree but am still looking for better suggestions and recommendations.
Rajarshi
Also, you are suggesting to work with interfaces, even with the UI. Will that be too "practical", considering the nature of UI codes (events everywhere). That way, also think about the number of maintainable classes that the architecture will be having - 1. Domain Model2. Domain Model Interface3. Presentation Model4. Presentation Model Interface5. UI6. UI Interface
Rajarshi