When NOT to use MVP/MVC?

Question

Okay this is a question that I could find but very few proper arguments for/against.

I appreciate the value these patterns provide for testability and separation of concerns. Especially in cases where we would have some sort of data store(s), that could presented to the user in different ways.

But consider an application where each model is only bound to 1 view. An example maybe an audio format converter, which could be just a small GUI sitting over (a) big API(s) back-end. The UI just needs basic validation (for paths and formats), and the rest is left to the back-end.

Would the benefit of using one such pattern here justify the extra code? Personally, I see it as an unneeded overhead, but I may very well be wrong, hence the question. :-)

EDIT:

The example application I wrote about here seems to have been distracting people from the main point of the question. I'm asking when MVP/MVC are NOT good. Here's a quote from the Golden 4:

No discussion of how to use design patterns would be complete without a few words on how not to use them. Design patterns should not be applied indiscriminately. Often they achieve flexibility and variability by introducing additional levels of indirection, and that can complicate a design and/or cost you some performance. A design pattern should only be applied when the flexibility it affords is actually needed.

And that's the main point of the question. I couldn't find those few words on how not to use [MVC/MVP], so the question is an attempt for just that. As I said above, I really appreciate the value they provide, but I want to know when they are a horrid idea. No pattern is good all the way for sure?

Answer 1

You might want to read some of the answers to this question : reasons not to use mvc architecture for web application

Furthermore, on this page you can read this: (by reversing the "why should I.." you might get some extra ideas too)

Choose MVC if . . .

You are well-versed in the architecture of MVC. If you aren't comfortable with how to design a controller, MVC probably isn't a good choice. You want full control over the HTML that is rendered in the browser and you can afford the development time and overhead to do all of your own markup. You need to create efficient unit tests for your user interface without the overhead of the entire managed runtime, etc. - You want full control over how your URLs are formed.

Choose web forms if . . .

• You are not familiar with designing MVC applications.
• You need to minimize development time.
• You want a feature-rich user-interface (such as GridViews, etc.) to display data with rich interaction without substantial development investment.
• You are already invested in server controls, either from your own development or from 3rd parties.

Other useful explanation here : You should NOT use ASP.Net MVC if... and what it says, in short :

• You are not very comfortable with polymorphism
• You aren’t willing to build on top of the framework
• You rely on 3rd party vendor controls for lots of the UI
• You are averse to using open-source libraries

Answer 2

In my opinion you never know what the small GUI become in the future. Therefor scalability is the best way to go. It doesn't only let you write neat code, later on (for example when somebody takes over the project) it will be clear very fast.

I used to write small sites on-the-go but quickly realised that this was a pain. Especially when returning to the site a year or 2 later.

Answer 3

You might as well do it anyway. You say you have a small GUI sitting over a big API - in my opinion, that's the best pattern you can have. That GUI can now be MVC or whatever, but, providing you have the M as your service/API you've got the important stuff right. If your tools let you quickly develop an interface at the expense of a bit more extra code, that's probably the way to go in my opinion. At least you've done it the right way around and will never have to unpick UI from proper code. The reverse is worse.

There are inefficiencies and bad practices everywhere and some are worse than others. This is not one that is worth the concern or brainpower. Wear the small cost of a bit too much code rather than the significant cost of a UI tangled beast where, for example, you can't change the colour of something because it breaks the business scenario it serves! Remember that programmer time is worth more than CPU time. If you ever consider N+1 SQL, using web services for reporting or sucking 1000GB of XML into memory then come back and ask again, but as it stands, I recon you're ok. :)

Answer 4

"An example maybe an audio format converter, which could be just a small GUI sitting over (a) big API(s) back-end." The question comes from this assumption of yours. However, there can be several interchangeable GUIs, or an IPC/RPC interface (turning it into a service) instead of the GUI, or TUI, etc. as well as several different conversion logics. Also, the UI does not validate anyhting as it is just for representation of data. Seeing it that way, the MVC pattern applies here as well.

No matter what data you have, the data itself can always be decoupled from its representation thus MVC can be used virtually anywhere (if your program has any kind of output). Simply put, the MVC pattern is a specific version of Separation of Concerns design principle that should be applied everywhere to produce high quality source code.

You shouldn't in any case have application logic in your UI, and you also shouldn't have environment-specific code in your business logic thus you'll need a layer between the two; that is, the controller. In the end of the day you'll end up having an MVC structure anyways.

Answer 5

Many design patterns can be disregarded if you know that your project will always remain small and won't change a lot over time.

But taking your example if the day comes that you decide to use the same audio processing code in a web app or a mobile app instead of your original desktop app, then your work will be a lot easier if you've structured your code according to mvc.