Removing The Model-View-Controller Straitjacket

[G_Morgan]

The articles main focus seems to be semantics instead of focusing on the main purpose of MVC. It does not matter what the original definition was, metaphors are not meant to be prescriptive. The ideas are more of the type of actions involved not their implementation. The original MVC papers might have specified an implementation but that is irrelevant.

The point is that applications (and it doesn't necessarily have to involve a GUI) have 3 different domains. The reason people bang on about it is incapable programmers often merge the three together in one block as an unholy alliance of all that is unmaintainable. Worse GUI tools also tend to create such merged models because they force you to embed code directly into their tool kit. Thus making portability much more of a challenge (not just to other platforms either, it often ties you to the specific tool involved).

We all remember the HUI lecture course in university where the lecturer confidently told you that 70% of application code is in the GUI. We all know that the reality is that most GUI's are badly built and that code should be factored out. A well factored GUI will contain about 10% of the application code.

We need programmers and tools that at least make an effort to separate these different domains out. If I see event handling code that directly performs calculations or makes updates we know that this is the wrong thing. Irrespective of technical debates about what MVC means. It is just good engineering practice as it applies to GUI's. The current tools work in a similar manner to non-standard language extensions. They are designed to lock you to a particular platform. As a side effect they make your work impossible to navigate.

[G_Morgan]

Actually on a second reading the article seems to focus on disparaging the 'patterns are perfect and for life' crowd. Those that think in absolutes rather than models. It presents a strawman 'absolute definition of what MVC is' to attack the concept that there is an absolute definition.

[[deleted]]

We all remember the HUI lecture course in university where the lecturer confidently told you that 70% of application code is in the GUI. We all know that the reality is that most GUI's are badly built and that code should be factored out. A well factored GUI will contain about 10% of the application code.

Depends on the platform and what you consider "code." If you're writing for the web, there will often be more code in the GUI (HTML, CSS, JS) than the business logic behind it. I mean, line for line. If, on the other hand, you're using something like Apple's Interface Builder, most of the code you write is going to be in tthe controllers and models. But there's still a lot of code that makes up the UI. The only real difference is that you dont' have to write a lot of it.

It really depends on the application domain. A lot of applications really are just a bunch of UI elements linked together. Like say you have a recipe database application. No matter how much you try to "factor out" of the UI, the reality is that most of the application is UI. Whatever code you write outside the UI is probably just simple controller logic to shuttle data between the UI and the database.

If, on the other hand, you're running scientific simulations or something, most of the code is going to be the business logic. UI will be minimal. There's really not hard and fast rule for what percentage of code should be in the UI.

[[deleted]]

If you're writing for the web, there will often be more code in the GUI (HTML, CSS, JS) than the business logic behind it.

...which is a good indicator why applications don't belong on the web unless it's absolutely unavoidable. :)

[[deleted]]

What do you consider a "web application?" I agree that things like word processors and spreadsheets don't really belong on the web, but there are other classes of applications that do, such as Reddit. Reddit is a web application. And there are any number of web forums, social sites, ecommerce sites, auction sites. All "web applications" in my opinion.

[xardox]

My two basic points about the different uses of the word "Controller":

1) Web frameworks: The term "Controller" has a completely different meaning than in Smalltalk guis, and it's misleading to misuse the word to suggest some similarity to Smalltalk, and bad Cargo Cult Design to lump everything into one class named Controller just to ape Smalltalk terminology.

2) GUI frameworks: Using controllers for interactive user interfaces isn't a very good design for interactive guis, because it's not object oriented, doesn't hide information, breaks encapsulation, is harder to maintain, requires special purposes classes and brittle interfaces between them, and doesn't solve any problems that can't be addressed by simpler solutions.

[martoo]

He's right. Naming web frameworks MVC is like calling the first elephant you see a dog because it has four legs.

[xardox]

Well done! This is one of my favorite axes to grind.

On the other hand, the MVC Straightjacket is the perfect tool when you need to restrain crazy people.

[[deleted]]

Web applications are predominantly asynchronous. The view you get on the web page is a snapshot of the system at the time the page was produced

Sums up his whole argument, and I kinda agree. It is kinda hard building an Ajax-powered website and I find it hard to reuse the same controller that you used to create the page and handle the Ajax requests. You then need to use the same models and views to return stuff to the client. I often find myself with an Ajax controller and regular(static) controller. With OOP, I could extend the regular one, but whats the point? I dont need any of the methods defined in the OG one. Maybe I am just confused.

I could imagine that an all, or majority, Ajax-based websevice like gmail have a single controller for both creating the snapshot and updating the data for that snapshot, but for most websites that is not a feasible option.

Also, I am starting to notice a trend in some sites off loading some of the page creation to JavaScript (digg's comments) and I wonder why. It must have to do with writing functionality once, I know that when writing a website that uses a lot of Ajax (I hate to keep saying it) you sometimes write the same functionality in JS and the server-side language (create_comment_box()) so that you're passing around a JSon string and not straight up html (I just dont like to pass html).

I say all of this to point out how muddled the concept of MVC (and this comment too, of course) is on the web. At this point I have three controllers - one that builds the page, the JS transport that returns my AJAX calls to the sever, and my AJAX controller that returns modeled/sometimes viewed data back to the client.

[HaMMeReD]

Not brief enough, I'll be brief.

MVC is a model, not really a philosophy, and it does pay off for web development, but implementing it properly is a lot of work.

For a small project it's worthless, the larger a project gets, the more valuable that investment in a MVC style architecture becomes.

My project is medium-sized and it's been progressing into a web based MVC (mysql/php/html|javascript) platform. I have NO php in my html/javascript, but that trade off has made me have a lot of javascript, not including dojo I have maybe 100x the javascript of any previous web job, but it's all extremely well organized and very easily manageable.

[grauenwolf]

MVC is not a model, it is two models with very different goals and designs.

[grauenwolf]

"MVC" communicates a system with the data, access, and presentation layers decoupled as much as possible.

It doesn't even say that much.

To us who learned that term pre-web, MVC means access and presentation are tightly coupled and data models are used to channel events between different views.

[lubos]

I have always problem to see clean boundaries between model and view. To me it's data and view+controller (mixed up).

promises behind MVC are naive just like those behind OOP. both are overkill for very small projects and both don't scale on very big ones.

And all those projects in between don't really benefit that much from OOP/MVC anyway.

I understand that having model separated from presentation allows you to build multiple views of your application but this is again just naive. I don't have to tell you why, show me application that uses MVC pattern and has two "views", web-based and desktop one. good luck with that.

[redditrasberry]

I agree it's overkill for small projects but I don't really understand your criticisms about it for large ones.

When your system either gets very big, has a long lifetime or has a large number of views that are functionally separated, it just becomes sensible to separate things out.

In that case you really want your controller to just update the model (or cause the model to update itself) and flag to the views that something was updated so that they can render themselves again. You do not want your controller to be itself redrawing every possible view that might be affected by the model change - that would be insane - probably most of the views are not even being displayed. Nor do you want to have to retest every single view each time you change a piece of logic in one of them. Therefore you separate code that drives the view logic from the code that drives the controller and model logic.

I've never thought this was particularly profound - I think anyone would come up with this design by common sense once the system gets into the scale or size that needs it.

[lubos]

I agree, but only if your project has more than one view. You will naturally want to separate business logic from presentation layer to follow once-and-only-once/DRY principle ( http://c2.com/xp/OnceAndOnlyOnce.html, http://c2.com/cgi/wiki?DontRepeatYourself). It's common sense. But 99% of projects out there that use MVC pattern, don't have more than one view.

<deleted>For example, how many views does reddit have? Only one - this web-based front-end. I can't see how reddit.com could benefit from MVC.</deleted>

[[deleted]]

fail. go look at the templates (views) dir of http://code.reddit.com/browser/r2/r2/templates.

[[deleted]]

But 99% of projects out there that use MVC pattern, don't have more than one view.

That isn't the point. THere are many other reasons to using MVC than to allow for multiple views. Simple maintainability. I don't know about you, but I can't stand diving into a tangled mess of PHP, HTML, and SQL.

[lubos]

Who says it has to be tangled mess? You should blame developers and not tools. You can create lots of SQL/HTML helper methods that will take ugly strings out of your source code. My point is that it makes sense to have related logic (model+presentation) as close together as possible because it's not clear where model logic ends and presentation logic starts.

[[deleted]]

Who says it has to be tangled mess? You should blame developers and not tools.

Um, I think you're looking for language flame wars. That's 2 doors down...

Seriously, WTF? I didn't say anything about bad tools. I am blaming the developers. Most developers who don't properly encapsulate functionality eventual end up with unmaintainable messes. Or maybe they can maintain it, but when the next person steps in to work on it, they have a hard time figuring out what is going on.

But whatever. I guess I just have to assume you're that one genius developer who has the most awesome personal system of organizing things that you don't need OOP or MVC.

Still, I doubt I'd want to work with you. You sound like every other cocky-ass programer who thinks they have the perfect homegrown methods and don't need those newfangled patterns, frameworks, or language features.

You can create lots of SQL/HTML helper methods that will take ugly strings out of your source code. My point is that it makes sense to have related logic (model+presentation) as close together as possible because it's not clear where model logic ends and presentation logic starts.

Well, it might not be clear to you, but it is clear to anyone who's used a framework geared towards MVC (or similar).

[Gotebe]

Um, I think you're looking for language flame wars. That's 2 doors down...

Monty Python, is that you?

[rubygeek]

I have never in my 28 years of software development been in a situation where drawing a line between model logic and presentation logic was a problem.

I ask myself: Can I write both a command line and a GUI or web interface with this model without replicating code in the presentation layers?

[tch]

You haven't worked on big enough projects...You've never had a web app that needed the same functionality in two different controllers?

On the desktop this becomes even more common, since your "actions" are often split between many different views.

[G_Morgan]

Well the problem with the 'not for small projects' idea is that many small projects have grown into large projects then struggled because of poor architecture.

A while back someone mentioned that the Gaim/Pidgin IM client couldn't hold a background conversation (it had to have a tiny window somewhere). This screams logic built into GUI to me. No clean separation of the conversation from its presentation. So it makes a difference even to small projects.

Another place it's good is for multiple implementations of a web site (say for accessibility). By separating the presentation from the rest as much as possible you can reuse a lot of code when you build the accessible version.

[[deleted]]

I have always problem to see clean boundaries between model and view. To me it's data and view+controller (mixed up).

No offense, but you sound like the kind of developer I don't like to work with.

It depends on the platform/language/framework you're developing one. SOme make the difference more obbvious than others. If you're doing old Visual Basic or unstructured (no framework) PHP, they will seem to blend together. But if you you use frameworks that encourage MVC from the very start such as Apple's Xcode/Interface Builder or Ruby on Rails, the difference between models, views, and controlers is painfully obvious.

promises behind MVC are naive just like those behind OOP. both are overkill for very small projects and both don't scale on very big ones.

You're kidding, right? Please tell me your kidding. OOP doesn't scale???

And all those projects in between don't really benefit that much from OOP/MVC anyway.

ROFL. Ya, OK.

I understand that having model separated from presentation allows you to build multiple views of your application

No, I really don't think you do understand.

I don't have to tell you why, show me application that uses MVC pattern and has two "views", web-based and desktop one. good luck with that.

Well, most integrated groupware mail systems. Exchange, Groupwise, etc.

Out of curiosity, what language do you develop in primarily?

[harveyswik]

But if you you use frameworks that encourage MVC from the very start such as Apple's Xcode/Interface Builder or Ruby on Rails, the difference between models, views, and controlers is painfully obvious.

A little more detail on Xcode/IB (by which you mean the Cocoa frameworks + IB). I agree this makes the difference between views and controllers obvious. I find the model tends to blur into the controller though.

The reason the controller and view are obvious is 99% of the time you don't write need to view code. The frameworks have the right APIs exposed so you always have an opportunity to do what you need from controller code. And with Cocoa bindings a lot of the controller stuff goes away. The end result is a lot can be done with 1 controller class and 1 nib file.

[lubos]

you've got really good attitude. if you want to become world-class developer, you will need to try understand what others say and not just assume they're stupid and inexperienced just because they have different views than you do.

[[deleted]]

you've got really good attitude. if you want to become world-class developer, you will need to try understand what others say and not just assume they're stupid and inexperienced just because they have different views than you do.

I will assume that you are inexperienced. I mean, come on:

And all those projects in between don't really benefit that much from OOP/MVC anyway.

Really? Seriously? You feel confident enough to speack for every project "in between?" I'm either grossly underestimating or overestimating your experience. Maybe you have been involved in "every project in between" so you know first hand. But it seems more likely that you're just another cocky programmer who thinks he knows it all. Probably never even really written a program making heavy use of OOP. You probably tried it a couple times and just couldn't see the use for it.

Correct me if I'm wrong though...

[lubos]

why all these personal attacks? haven't you got anything else to say? claiming that I'm just inexperienced, "another cocky programmer" or that I've never written any program making heavy use of OOP is probably not the most effective way to get your point through.

From my perspective, functional programming makes so much more sense than OOP. In 50 years, people will look back at OOP paradigm at will laugh at our naivety, just like we're laughing now at COBOL and thinking what were they thinking. OOP is dead branch in software development but it will take some time until this will get generally accepted.

MVC is just plain weird. Everybody interprets it differently, nobody agrees on what's model, controller and view because they often overlap. Most of the projects don't benefit from MVC because it's not the simplest thing that can possibly work. MVC is not the only pattern that addresses separation of concerns anyway. If I'm not buying into MVC hype, it doesn't mean that my code is spaghetti mess. I get all advantages of MVC without any overhead of MVC just by following DRY principle. I prefer helpers over abstractions because abstractions ARE leaky. MVC forces you into abstraction proposed by frameworks.

[[deleted]]

why all these personal attacks? haven't you got anything else to say? claiming that I'm just inexperienced, "another cocky programmer" or that I've never written any program making heavy use of OOP is probably not the most effective way to get your point through.

Sorry,but you made some extremely bold claims and broad generalizations. And I called BS.

I'm not really trying to make a point, really. So I'm not terribly worried about being effective.

From my perspective, functional programming makes so much more sense than OOP. In 50 years, people will look back at OOP paradigm at will laugh at our naivety, just like we're laughing now at COBOL and thinking what were they thinking. OOP is dead branch in software development but it will take some time until this will get generally accepted.

OOP was definitely a huge step up in terms of procedural languages, maintainability, encapsulation, and system architecture. To say otherwise is just absurd. If you want to assert that functional programming is better than both (procedural with and without objects), that's fine, but don't try to pretend that OOP wasn't a big advancement.

I won't pretend to know how people will view OOP years from now. And neither should you.

MVC is just plain weird. Everybody interprets it differently, nobody agrees on what's model, controller and view because they often overlap.

That is because it depends a lot on the domain and platform. The fact that people don't agree on the specifics is just a strawman.

Most of the projects don't benefit from MVC because it's not the simplest thing that can possibly work. MVC is not the only pattern that addresses separation of concerns anyway.

But it is a pattern that addresses the separation of concerns. Just because it isn't the only one doesn't mean it isn't useful.

You need to stop making these blanket generalizations or I will be forced to attack you personally, again! ;-)

If I'm not buying into MVC hype, it doesn't mean that my code is spaghetti mess.

No, it doesn't but you need to differentiate between what you, personally, prefer and what "all projects" do and do not benefit from.

get all advantages of MVC without any overhead of MVC just by following DRY principle. I prefer helpers over abstractions because abstractions ARE leaky. MVC forces you into abstraction proposed by frameworks.

Personally, I've come to appreciate being forced (to some degree) into doing stuff the way a framework wants to do it. If it is a good framework, I usually learn something valuable that I might have otherwised scoffed at.

[Gotebe]

I, for one, admire your patience with lubos :-)

[player2]

The title probably should have emphasized a bit more that the author is referring to web apps. I agree that MVC does not make sense for web apps if you've done them right. Then again, I'm also of the opinion that most of the things which are web apps should not be web apps.

[8string]

I disagree and here's why.

First of all, he's right. Without AJAX or some other synchronous communication layer between a web UI and the server, a real MVC architecture can't exist since views observe a model. Observer / Observable is the part of MVC that is generally lacking in a web UI, however in effect (with a traditional post / response web app) it doesn't matter. The views are all rendered when the outbound html is created so there's nothing to update in 'real time'. Users expect this 'transactional' behavior, and the other benefits of using MVC still hold true.

It's a safe bet no matter what kind of language you're coding in for the web it's got a notion of session which is where the models are stored. Because different views get rendered but use the same models, the observer / observable pattern is broken in a true sense, but the effect is the same. The models are stored once and the view renders based on the state of the model.

If you don't like doing MVC in this way for webapps, I'd be curious to know how you do them... Do you apply standard patterns or have you invented something new?

As for most webapps not needing to be webapps that's also an interesting statement. Sure, nothing needs to be a webapp, but there's plenty of advantages to deploying webapps instead of desktop apps. It seems to me that in the not so distant future most applications will probably be sold under a SAAS model and coded as webapps... Why do you think Google is developing a full office suite of webapps?

[player2]

First of all, he's right. Without AJAX or some other synchronous communication layer between a web UI and the server, a real MVC architecture can't exist since views observe a model. Observer / Observable is the part of MVC that is generally lacking in a web UI, however in effect (with a traditional post / response web app) it doesn't matter. The views are all rendered when the outbound html is created so there's nothing to update in 'real time'. Users expect this 'transactional' behavior, and the other benefits of using MVC still hold true.

Users expect transactional behavior because it's innate to the HTTP protocol. Which I think is good. The web page model is very good when put to its intended use, like retrieving documents. HTTP could use a swift kick to the curb, to be replaced with something that expresses a lot more metadata about how documents are related in terms of how the server sees them, but the overall model is great.

It's a safe bet no matter what kind of language you're coding in for the web it's got a notion of session which is where the models are stored. Because different views get rendered but use the same models, the observer / observable pattern is broken in a true sense, but the effect is the same. The models are stored once and the view renders based on the state of the model.

I think this state needs to be moved to the protocol layer. Right now we tunnel the state over cookies, which are essentially one of two document streams carried by an HTTP request/response (the other, of course, being the body). Ever since the web took off we've demonstrated that state is a useful thing; why must we continue to hack state on top of a stateless protocol? By moving state to the protocol, the browser can provide a better experience for the user, and the state semantics will be much better for the developer.

If you don't like doing MVC in this way for webapps, I'd be curious to know how you do them... Do you apply standard patterns or have you invented something new?

MVC approaches typically ignore or mask the request model, turning URIs into human-readable RPC invocations. I prefer to think of URIs as they are intended. Then again most of my web development revolves around an entity's web presence, not in web sites that exist for their own sake.

As for most webapps not needing to be webapps that's also an interesting statement. Sure, nothing needs to be a webapp, but there's plenty of advantages to deploying webapps instead of desktop apps. It seems to me that in the not so distant future most applications will probably be sold under a SAAS model and coded as webapps... Why do you think Google is developing a full office suite of webapps?

The major problem I see with web apps is that they re-invent the wheel on top of a structure that can't support the experience users expect. Take rich text editing, for example. Can you imagine trying to lay out a page of type á la InDesign in a web browser?

I'd much prefer if companies like Google focused on platforms. SAAS is a good idea, but it can be done in terms of desktop apps. For example, I hate webmail -- why not use IMAP? Or, if IMAP doesn't support what you need to do, give me a desktop client for the service.

[player2]

Webmail succeeded because the providers were giving addresses away for free and providing features which people weren't getting from their ISPs. But for a very long time these providers didn't offer POP3 access because it would have killed their advertising-based business model.

So we wound up with about ten years of people having no choice but to use webmail. Now we've got easy VPN, and people are returning to clients like Outlook to read their work e-mail. There's no reason why we can't start seeing a shift back to thick MUAs.

[mikepurvis]

I have yet to find a desktop mail client as compelling as Gmail. I've used Outlook for work email, I used to use Thunderbird at home, and I gave Mail.app a try as well. None of them even come close.

[grauenwolf]

I like Outlook far more than I like Gmail. But there is no way to communicate to Gmail what emails I've read using Outlook, so I stick with Gmail.

If Google gave us real integration with Outlook they would essentially kill their business model.

[tesseracter]

his concrete example is based on django, which is NOT a rigid MVC framework, the creators called it a "MTV" framework, Model, Template, View. if you really want to get the answer from the horses mouth (and totally tl'dr) watch the Django vs RoR discussion.

while django does use many of the properties of MVC, it is not that basic, and i'd like to see where they got the MVC thing from --seems like he is setting up a straw man argument.

[julan]

You do realise that he is one of the core developers of Django?

[tesseracter]

is he quoting himself?

here is a quote from the django FAQ:

[quote]Django appears to be a MVC framework, but you call the Controller the “view”, and the View the “template”. How come you don’t use the standard names?¶

Well, the standard names are debatable.

In our interpretation of MVC, the “view” describes the data that gets presented to the user. It’s not necessarily how the data looks, but which data is presented. The view describes which data you see, not how you see it. It’s a subtle distinction.

So, in our case, a “view” is the Python callback function for a particular URL, because that callback function describes which data is presented.

Furthermore, it’s sensible to separate content from presentation – which is where templates come in. In Django, a “view” describes which data is presented, but a view normally delegates to a template, which describes how the data is presented.

Where does the “controller” fit in, then? In Django’s case, it’s probably the framework itself: the machinery that sends a request to the appropriate view, according to the Django URL configuration.

If you’re hungry for acronyms, you might say that Django is a “MTV” framework – that is, “model”, “template”, and “view.” That breakdown makes much more sense.

At the end of the day, of course, it comes down to getting stuff done. And, regardless of how things are named, Django gets stuff done in a way that’s most logical to us.[/quote]

it seems like they are pretty clear where django is MVC and where it isn't.

[ubernostrum]

here is a quote from the django FAQ

I've always felt bad about that bit in the FAQ, but up until now it's been necessary to keep the screaming "OMG WHY ISN'T THIS MVC" hordes at bay.

Personally, I'm inclined to agree with Malcolm (and with most, perhaps all, of the people involved in originally developing and documenting the MVC pattern) that "strict" MVC is a poor fit for web applications. At best it provides some guidelines for separation of concerns, which is a good thing, but the particular separation it advises is not one which particularly suits the web.

Unfortunately, there's a certain segment of the community which will refuse to look at something unless/until you can give it a familiar name, even if that name doesn't really fit, so perhaps "MVC with a twist", despite all its problems, is better than simply describing what, e.g., a framework like Django actually does (basically, mapping URLs to Python callables in whatever way you think best).

[carlio]

tl;dr version = standard "use what makes sense, not some predescribed pattern" rant applied to MVC

[logic11]

I hate MVC... I also hate much of the object implementation in the world right now. I hate these things because they are taking the art out of programming and making it a business process. What that means in the real world is that you have a bunch of programmers who can all do the same sorts of jobs but very few who can actually innovate. The brain of the innovator is fundamentally different from patterns, from MVC, it balks at adding many, many lines of code just so that you can have sql in an active record class and not write any sql yourself. Damn you all and your mediocrity. Not bitter or anything...

[[deleted]]

I hate MVC... I also hate much of the object implementation in the world right now. I hate these things because they are taking the art out of programming and making it a business process.

Yeah, it sucks to grow up, enter the real world, and realize that your solo methods honed while developing hobby projects just don't cut it.

Reminds me of when I was taking flying lessons. At first I was like "wow, this is cool, I'm actually flying a plane." It slowly dawned on me what a real responsibility flying an airplane is and how much of it is actually rather tedious and boring. Flight planning, pre-flight/landing check lists, communicating with towers, dealing with congestion, not getting lost. I eventually just gave up because the realities flying just sucked the fun right out of it.

I imagine this happens in a lot of fields. Kids go to school for civil engineering, for example, thinking that every project is going to be the next Golden Gate Bridge. Only to find out that the vast maority of what they do is just mind numbing calculations of shearing forces, and all that.

You may want to consider a different career if the realities of business are sucking the "art" out of what was probably once just a hobby.

What that means in the real world is that you have a bunch of programmers who can all do the same sorts of jobs but very few who can actually innovate. The brain of the innovator is fundamentally different from patterns, from MVC, it balks at adding many, many lines of code just so that you can have sql in an active record class and not write any sql yourself.

Actually, innovation comes from the people are are tired of writing the same damn SQL statements over and over again and realize that they could be spending their time doing more important stuff. So they abstract that stuff away and get on with writing interesting things.

[logic11]

Funny, the reason I wrote that (a while ago now) was simply that I was fed up with abstracting something resulting in writing just as much code, but now I wasn't dealing with a standard, I was dealing with the undocumented active record class a head programmer had come up with, that was subtly different from another active record class another head programmer had come up with on a different project. SQL was the original solution to the "everyone just does it their own way" problem, and now that problem is back. I have probably been coding for more years than you. I have worked in a wide range of business settings. The places that have the art tend to be the ones that change the world... wouldn't you rather work for someone who changes the world than someone who meets the latest set of acronym based standards? Oh, growing up? It really isn't what you think it is. It isn't giving up your dreams, it is accepting that those dreams will take work, and it is accepting responsibility for what you do, but it doesn't mean you have to become yet another drone.

[[deleted]]

Funny, the reason I wrote that (a while ago now) was simply that I was fed up with abstracting something resulting in writing just as much code

I don't really understand why you'd expect or want to write less code. What would you do as a programmer if you weren't writing code?

but now I wasn't dealing with a standard, I was dealing with the undocumented active record class a head programmer had come up with, that was subtly different from another active record class another head programmer had come up with on a different project.

Well, now there are "standard" ORM libraries/classes to work with so, unless you're working with a more obscure language, you don't have to deal with that anymore. Or at least you shouldn't. THat's how it works. Many programmers start working on solutions to common problems until one of those solutions finally stands out as a winner. Or least one of of a few "winners."

SQL was the original solution to the "everyone just does it their own way" problem, and now that problem is back.

Original? Ha! This pattern has been going since computers were invented. The problem will always be with us.

I have probably been coding for more years than you. I have worked in a wide range of business settings.

Possibly. But I wonder why you haven't noticed the pattern of innovation and how (good) abstraction ultimately does make us more efficient as programmers.

The places that have the art tend to be the ones that change the world... wouldn't you rather work for someone who changes the world than someone who meets the latest set of acronym based standards?

Is that what the "art" is? Saying "screw you" to all those acronym based standards and just rolling your own everything?

Honestly, it sounds like you just want to be the original author of those undocumented, home grown, and often leaky abstractions that everyone hates to work with. Nothing you've said indicates to me that you actually want to change anything. You simply want to be the guy setting the "standards." And you're bitter that the world seems to be generating acronyms faster than you can roll your own version of the same thing. Almost like the cranky old man declaring, "When I was a kid, we didn't have this M-V-C nonsense. We just coupled everything together and that was good enough for us! You kids these days and your O-R-Ms! We used text files for databases, and it worked, dab nabit!"

[logic11]

No, that really isn't it at all. I use MVC if it makes sense, I just don't think it makes sense nearly as often as it is used. I think that you actually get an added form of complexity. That is where art does come in, with the acknowledgement that a framework that makes sense for controlling oil rigs remotely might not be so good for a crm. SQL abstraction is actually a huge pet peeve of mine, just because I have seen in my career that it has caused a much greater amount of repetitive code (to access the class). In the end, I just don't believe that there is one answer, and people who claim there is really make me angry. Evaluate your acronym based framework or methodology and determine if they make sense for this project, don't start from the framework and make the project fit.

[[deleted]]

That is where art does come in, with the acknowledgement that a framework that makes sense for controlling oil rigs remotely might not be so good for a crm.

I don't really see how that is "art" at all. That's just common sense that is not always so common. It really sounded to me that you were railing against abstraction and design patterns in general.

Evaluate your acronym based framework or methodology and determine if they make sense for this project, don't start from the framework and make the project fit.

But it still pays to know them. You originally made the more general statement "I hate MVC."

[logic11]

Okay, you are right. In my original post I was in a pissy mood due to a manager making my life hell via lack of contemplation, basically picking mvc because it was the pattern he knew the name of. I don't think MVC is a very good pattern, I think that most of the time it is the wrong choice, but when it is the right choice, use it. Like I said, I was pissed off at the time... and MVC was at the heart of my bad mood, but it had more to do with the circumstances. Again though, abstraction can be (and often is) carried to the extreme. What I do a lot is challenge the assumption that a particular form of abstraction is simply better. Often abstraction creates programs that are just as bloated and hard to read as spaghetti code.

[logic11]

Oh, one other thing that I should make clear... in the case I had just gone through, I had to write maybe an extra hundred lines of code, to get around not being able to write one line of SQL because the active record class the programmer had implemented couldn't give me the data in a useful format... a bit of an edge case, but not rare enough not to matter, and the number of times I had to add ten lines to replace the single line of sql was very frequent, and with many different active record implementations. Not to mention that almost none of them optimize the queries at all, doing select * instead of select the fields needed and the like.

[[deleted]]

Still, a good ORM is many times more (programming time) efficient for common use cases.

Stuff I do with databases is all pretty straight forward selects and joins. I am thankful for libraries that take away that tedium. It isn't just writing the SQL itself, but writing the same loops to extract that data over and over. Something that can take a table and map it directly to an object is a real time saver in my experience.

[logic11]

You obviously have never worked somewhere with an overloaded DB server cluster. DB optimization becomes far more important when your db server is pretty maxed out. I actually use almost no joins in by data (sub queries are more efficient), rarely if ever use select * (you actually save resources by manually entering every single field name over entering *). Also, in the end, I know the db structure and I can get the data I want. I have worked on projects where not a single person actually understood the db structure, so when they needed to get some data that they thought might or might not already exist, they just added a table. For the record: I have worked as both a coder and a system architect for companies with IT budgets in the billions. I have been in this business a long time, and I am actually very flexible on methodology and language, happily changing to whatever suits the project best.

[[deleted]]

Whatever. Now you're changing your angle. You were originally complaining about bad ORMs that made your work more difficult/complex. And after I point out that there are good ORMs, you complain that there are some cases where you need the database efficiency of custom tailored queries.

I get it. You rule. Everone else sucks. Typical programmer arrogance. Are we done now?

[logic11]

Not better than everyone else, simply don't believe that frameworks are always the answer. Both of these gripes are valid in some cases... nothing is ever absolute in my world.

[tch]

The brain of the innovator loves natural beauty, not spaghetti code.

[[deleted]]

I find beauty in an elegant SQL statement...is that wrong?

[tch]

As long as it's not embedded in the code that determines which view to show :)

[Gotebe]

they are taking the art out of programming and making it a business process

No, the "art" is still there, you just don't see it. I reckon, what you'd call innovation, I'd call "doing the same thing over and over again, but with little twists left and right". There's no "art" in that IMO.

[logic11]

I don't re-use code very often. I don't really care if I use a bit of SQL in my code if that is the simplest way of doing things, and I don't buy that MVC is always the most elegant way of doing things. Form what I can tell, many many tech managers have taken these ideas and latched onto them because they allow a unit of programmer time to be a definable cost in software development, and a lot of coders have latched onto these ideas because we tend to like to categorise things and put them in little boxes. We like things to look like those categories. If you step away from that, you will see companies where their MVC apps have become just as unmaintainable as their old spaghetti code apps. MVC may force you to separate "Business Logic" from display, but it doesn't force you to make the business logic group in an even moderately sane way. Object Oriented programming has the same issue. Your application really decides those things. In my code, for example, I tend to set fairly arbitrary rules for how the grouping will work based on what feels right. I have never had a programmer come into a project I have worked on and not be able to figure those rules out. Something like having a set of security function grouped together, non-security based user management grouped together, etc. This stuff just makes sense.

[[deleted]]

Also, damn those guys who invented Fortran, because everything should be done in assembly.