Clean, Modular Code vs MV* Frameworks [closed]

Question

I've been hearing a lot about the "new" MV* frameworks. I've tinkered with KnockoutJS (I created an invoicing application), but I much prefer to write clean, modular code in raw JavaScript - leveraging utility APIs and other libraries when necessary.

Given a methodical/structured/SOLID approach to writing a JavaScript application, where OOP, SOC, SRP and other design principles are adhered to, wouldn't the usage of MV* frameworks be superfluous?

Are there any articles that express/address these concerns?

I've found one in the past

note - I've migrated this question from SO to this site, as its more appropriate for this audience.

Answer 1

Clean code always trump any architectural models, in that if you give me the choice of clean, understandable code that's not written in a MVC way, or nasty convoluted code that does fit in a MVC way.. I'll take the former.

there are disadvantages to these things. John Gossman said of MVVM (the WPF model-view-viewmodel version of MVC) that it is overkill for small projects, and the complexity of designing it can be too much for large projects. He also said the resource usage can make it unsuitable for medium sized projects too :)

So separation of code into presentation, logic and data tiers in some way is a good thing, makes your code simpler to write, and allows you to manage each section in isolation. Whether that means you must use an existing MVC framework is another matter however, as Gossman said, your exact requirements for your project may be different enough to those defined for a MVC framework to make that framework more trouble than its worth. As always, there's no silver bullet.

Answer 2

The thing is - if you write clean and modular code in a complex applications (I mean application with lots of UI functionality, since the question was particulary about JS and MV* frameworks), you will realize, eventually, that you are doing an application in MV* style. It could have another implementation and code look, but it will be MV*-application. I couldn't bet here, but I am 95% sure it will be that.

MV*-architecture is not a kind of fashion, or killer-feature, or something that could be thrown out. It is a pragmatical way to organize rich UI-applications to tackle complexity of the modern programs.

Answer 3

I see following reasons for the use of such frameworks:

1. Not everyone structures code by default. Frameworks enforce structure to some extent. This extent is variable based on how much scaffolding they provide. Too much scaffolding usually translates to steeper learning curve.

2. Frameworks generally encapsulate design/programming patterns from the collective experience of a larger community, so in some cases there will already be structure in there, while you will build and refactor.

3. Mostly developers will come and go, using popular/standard frameworks makes it easier for developers other than the original developer to understand the structure. Good frameworks are well documented and have active communities to be able to ask for help.

4. As you move from project, you most likely copy/paste code from previous project that you now require in a new project. In case you use a framework even if its your own MV* framework, you just import and include this framework each time.

Answer 4

There are a number of items that need to be addressed from your question. I'm going to say MVC when what I really mean is "MVC and all of it's related variants."

I've been hearing a-lot about the "new" MV* frameworks.

As you should; there's a number of advantages (and disadvantages) to using an MVC framework or similar.

Also keep in mind that MVC has been around since the 70's and was first popularized with the use of SmallTalk. See Martin Fowler's various essays on GUI architectures for additional information.

but I much prefer to write clean, modular code in raw JavaScript

So you should see the appeal of MVC then. :-)

MVC was created to help enforce the exact thing you're proclaiming to want within your code. UI's (Views) change. Logic to drive the UI (Controller*) changes. Data sources and access mechanisms (Model) change. MVC was designed to encapsulate change and give the best odds for each component to be migrated to the next incarnation of the application. By separating out the layers into individual components, the risk of change is minimized.

_{* By Controller, I mean the modern use of the term not the original use from SmallTalk days. And if that doesn't make sense, then ignore this sidenote.}

Given a methodical/structured/SOLID approach to writing a JavaScript application, where OOP, SOC, SRP and other design principles are adhered to, wouldn't the usage of MV* frameworks be superfluous?

Perhaps it's superfluous, perhaps it isn't. How big is your application? How devoted is your team to "doing the right thing?" How well does your team understand the domain and where responsibilities should lie within each and every single class?

That's a lot of dependencies on others that you're introducing there. Of course, your code is perfect and you'll never make a design mistake. But how are you going to shield the project from the human fallibility of others? How are you going to shield the project for the complexities of scale? A handful of views is nothing to keep in your memory. But what about hundreds?

MVC provides structure to help avoid some of those problems.

But at the same time, MVC isn't a silver bullet. Here's some of the valid criticisms against it.

• It tends to be heavy weight for implementing. Where you could have gotten away with 1 class, you'll now have three. On smaller projects, you're right to question the benefits of MVC.

• It can be frustrating to stay within the structure of MVC. There's always the temptation to let Controller code bleed into the View, or let the View directly access the Model. After you write your umpteenth wrapper function, you'll wonder why you're doing it.

• MVC presumes your app will live forever and will change technologies. If you never change the UI, the data source, or the business logic then you kind of wasted your time in encapsulating those layers in anticipation of change.

In summary, MVC is a tool just like any other. Its longevity and resurgence in awareness proves how valuable it has been. But it's not a silver bullet, not a panacea for all programming ailments. Understand it and use it (or not!) as appropriate for your projects.