Is MVP always worthwhile?

Question

Is MVP considered best practice for *all* GWT applications?

• What about for a small in-house web application?
• Is it a mistake not to use unit testing for such application, or any application?
• For an application that is not going to be unit tested, are there other reasons I might want to use MVP?

Answer 1

I can see merit in the MVP paradigm, but for myself I prefer not to have an extra presentation layer between the model and the GWT specific view classes. I make sure to rigorously keep all business rules out of the view classes (the UIBinder stuff), and put it in the model classes instead.

Likewise I keep all GWT.create(..) stuff out of the model. This lets me access the model classes on the server-side without hassle. I then use SyncProxy a lot in my JUnit tests for the RPC calls.

Ultimately, when you´re writing a rich web client, you can´t rely too much on automated testing of the view, especially not when it´s rendered by generated code for a variety of platforms (i.e. browsers). The proof of the pudding is in what Internet Explorer, Firefox and Chrome makes of it.

Answer 2

1. In general, MVP is considered a Best Practice for developing GWT applications. Several reasons to apply the pattern can be found in this Google I/O Presentation.
2. MVP comes to a price, and it will introduce several more classes and complexity to your application. But it will also minimize coupling and it will make your application more testable; so it is up to you as a designer to decide if the pattern is worth the pain.
3. Some methodologies - like Extreme Programming - encourages the inclusion of automated tests in a software development process. Again, the inclusion of tests will require your team to write more code, but in exchange your code will be robust and trustworthy. I strongly suggest you to include unit tests, even if the application is small.
4. As I said before, easy test is one benefit of MVP but it is not the only benefit. According to this article from Google:

MVP decouples development in a way that allows multiple developers to work simultaneously

Answer 3

Well it's subjective, design stuff are always trade-offs.

Although the scope/size/future of small apps is also debatable, we usually keep things simple for small apps to reduce complexity or avoid killing fly with a canon

However, if your team is already comfortable with MVP, I would strongly recommend to go for MVP because as it's size will increase, pattern will help you avoid spaghetti code.

Answer 4

Not using MVP does not necessarily mean not-testable. You can always test your app through the UI using automated testing tools, but those are harder to write and more fragile. If your application is complex, or you need to maintain it, making it unit testable will pay on the long run.