Hi,
I'm working on .NET 3.5 form application with slightly complicated behaviour. It's for a book inventory. To give you an idea, a workflow would be:
- The user enters an ISBN code
- If the ISBN is valid, check whether it exists,
- If it's valid and it exists, show book details and enable save button, if not, show 'add book'-button,
- If it's not valid, show error,
- Eventually, the user will click 'save', so the entry will have to be saved.
That's four responsibilities:
- Validate ISBN,
- Check book existence,
- Show book details,
- Save new book details.
My question is: Should I keep the application logic in one MVP-structure or should I split it into four MVP-structures, one for each responsibility?
Keeping it in one MVP-structure would
- make the model more complicated
- make the tests setup more complicated (lots of setup code for each test to choose the right validator,returned book etc. even if they're not used),
- make the presentation logic easier to follow
Keeping it in separate MVP-structures would
- make the model simpler,
- create more but simpler tests for each presenter,
- put complexity in the interactions between the presenters (how would I signal a presenter that an ISBN is valid so that book details can be shown?)
I'm trying for the Presenter First-principles, so: - Keep the view dumb (so no events like "Presenter one validated the ISBN"), - Keep the presenters stateless, - Keep the models simple (enough)
Anyone has an idea on what's the best way to do this?