Warning: Cranky day, cranky post... 

I've come across several posts this year (and last) about MVC/MVP and patterns in general.  I'm sick of MVC/MVP.  I'm sick of the Pattern Police - everything must be a pattern - hmph!

MVC was created to solve hardware problems while developing SmallTalk, this is something rarely mentioned.  It has been overplayed in the real world.  MVP is just a glamorized version of MVC, dah...I know what you're going to say...just shut it...it's a glamorized verision of MVC...dah...shhhh...it's a glamorized version of MVC.

Microsoft first sold ASP.NET (if anyone can remember to 2002) as the perfect MVC implementation because of the code behind model.  The HTML was your view, the .NET framework was your controller (it handled the events, page redirects, etc) and the code behind was your model (or was a facade for your model...i.e. the BLL).

Now a short 6-years later Microsoft says ASP.NET is not MVC and now ASP.MVC is a true implementation of MVC.  History repeats itself.  I'm sure in 2012 Microsoft will probably say that isn't correct either.

About two years ago everything was Factory/IoC/DI...

This just reflects a trend that has really bothered me for a few years now, but lately has been driving me bonkers.  Patterns, patterns, patterns.

I wish that people would stop worrying about 'what pattern should I use?', 'what Agile manifesto author should I idolize?', 'What tool is the best for writting this application'.  I wish people would stop sitting there justifying 'I need to spend a huge chunk of project time making the GUI, which doesn't have any real programming in it (business rule validation, program logic, persistence logic, etc), testable by adding a bunch of interfaces to it (along with every other thing in the application) so that XXX test framework can be used to automate testing of it'.  I mean why the heck would they try to make a simple intuitive user interface for the user that would be significantly easier to test by hand or with a quality COTS testing tool that specializes in testing GUI's when they can use a 'cool' open source program endorsed with a picture of Martin Fowler giving it a thumbs up all for the low, low price of delaying the project (now and in future releases and maintenance) to put in all those interfaces and extra moving parts, compromising security by exposing more methods and variables as public (so the testing framework can see it), and giving the user a GUI that makes no sense to them but IT'S TESTABLE, it's IN VOGUE and IT'S COOL.  Users!  Who cares what they think right?  They just pay your salary.

So instead of all these people out there preaching about how MVC/MVP, IoC, DI, etc, etc allowed them to write an application that walked on water over and over again until I want to rip my screen off the desk and throw it at there smug faces, how about they preach about demanding, or even writing themselves, good software by first and foremost illicitng good requirements!   Over the past 20 or 30 years or something the amount of bugs attributed to requirements has been 50% of the bugs reported (IBM web site has a wonderful article on this if anyone cares to Google for it).  This hasn't changed in decades!  Hell, something similiar is mentioned in the Mythical Man Month and that was written in the 70's!!!  We have higher level languages, fancy testing tools that magically make you write better software, project tracking and requirement tracking tools out the wah-zoo - but damn it to hell if I can get more than a 15 bullet point email of the requirements for a $150K+ project or a Power Point presentation that is just a bunch of pictures pointing to a database icon.

Then after they drone on about getting good requirements they can drone on about sitting down as a TEAM and discussing how to implement the REQUIREMENTS using several candidate architectures - it's like woman and marriage - you generally don't go with the first one you come across that will do what you want.  This does not mean you pull out your ORM tool and start generating your objects off of a database design (how are you sure your even going to need a database?  Not everything in this world has one...my web browser isn't connected to an AS400 somewhere).  This does not mean that you pull out a code generation tool to start stubbing things out for you.  This means looking at your use cases, your supplementary specifications, your exceptional flows, your non-functional requirements, etc., and write out some data flows, activity diagrams, whatever, just something where you are getting the design written on paper/index cards/post-its/whatever.  That way should you choose to use PHP, PYTHON, RUBY, JAVA, .NET, C++, FORTRAN, WHATEVER, the design WILL WORK.  After you've done all of this, then you can start thinking about the implementation.

Am I saying that you have to be documentation Nazi?  Heck no, I hate paperwork; I do as little as possible.  But you have to have something to refer back to and it should be something that is timeless (the requirement will still be valid 10 years from now when we're all working with interactive holograms).

Anyway, I digress, but in short, every developer should read in order:

  • The Inmates are Running the Asylum
  • The Pragmatic Programmer
  • Pragmatic Unit Testing
  • Martin Fowler's - code smell 'SPECULATIVE GENERALITIES' - can't believe how many of you out there worship him yet haven't read about that code smell or can't see it in the code you write!  And hey, for the record, I like the guy a lot - he's smart - but I don't mindless follow his every word without thinking for myself - that's how you end up on a 500 acre ranch in the middle of Texas with the AFT burning you to the ground.

Now back to MVC/patterns:
Using a Pattern does not a good program make - in fact more often than not I've seen or heard about it making a program overly complex and have a sky high maintenance cost around it.  I've seen developers scratch their head and spend hours and days trying to implement a pattern from 'Enterprise Design Patterns' because the 'usage' was roughly what they thought they needed; only for me to come in and make it work using that hard-wiring between my ears to just solve the fricken problem in a testable, maintainable, and well commented (i.e. documented) way.   And like any scam artist, those who will respond to this will say it's the person who implemented it - it's thier fault, not the fault of the pattern - oh no it can never be the pattern.  $10 bucks says someone will say it.

If you gather what the industry experts consider good requirements - or heck decent requirements, design before you think about classes, patterns, database FK relationships, and work without the crutch of a design pattern book and/or website, you will grow in YOUR knowledge, and with YOUR experience you will find that your code naturally falls into patterns all on its own when it's required.  You will also find your code less complex, easier to test, and easier to maintain...but why would you want that when you can just by a design pattern book for $69.95 which will magically improve the quality of your code.

Am I saying patterns aren't needed - no.  Patterns are a good thing, there are many, many talented people out there who are leaps and bounds smarter than me that use them with astonishing results.  They can help you trim the edges on your code (we all know how to cut a circle in paper, but we use a pattern to make it a perfect circle), and standardize it with others out there in the industry.  But I will say this much - those people (the one's I know of), don't start a project by thinking how a combination of Command, the use of an ORM against the ERD they just sketched out on paper will solve all the projects problems.  They also look at pattern books as a refresher book, not a recipe book.