Is the MVC (Model View Controller) paradigm a better way to develop or just a new complex one?

I was trying to use RoR or ASP.NET MVC but at my first impression it seems to me that MVC is a drastic way to change the programming paradigm. Is this just my resistance to changes or it is really weird? Some times i feel really lost! Any suggestion or I just have to turn back and program in the old fashion way?

From stackoverflow

• MVC isn't particularly new. It dates from 1979 (reference), so it's old enough to drink.

  In general, MVC forces a form of encapsulation upon you; that is, your View needs to be largely independent of your Model. Once you get used to it, you will find it useful; that said, for your individual needs, other paradigms may be more appropriate. MVC isn't the end-all, be-all; but it IS a useful way to look at some problems.

• MVC is neither new nor particularly complex. MVC is a standard paradigm that has been around for a long time. I remember it being one of the highlighted patterns in my Software Engineering classes 10 or so years ago. MVC, once you understand it, provides a very clean, testable implementation for your project. It's certainly different than WebForms -- and knowing WebForms can actually be a hindrance in learning ASP.NET MVC -- but I'm not planning to go back. I only expect ASP.NET MVC to get better and better as we see the same sort of controls built up for it that there are for WebForms.

• What is your basis for comparison? If you're used to perl / CGI, then maybe it is a bit more complex!

  In web terms, MVC (or Model-Template-View as preferred by Django, to separate from the original Smalltalk MVC) tends to allow for better separation of concerns in your application. In my (and many others) experience, this leads to more extensible, well-tested code that is easier to maintain.

  Some suggestions for going forward. It's hard to make specific recommendations without knowing a bit more about your background, and learning can be such a personal thing anyway:

  • RoR - Sam Ruby has a new book out. There are various screen-casts.
  • Django - I would recommend that as well, since those are the two web frameworks that have the least friction out of the ones that I've used.

  Sorry, I've been off the MS platform for a few years, so I can't offer any advice on ASP.NET.

• It only feels drastic because its new. It's actually not that bad.

  Taking a look at a real life application may help.

  Check out http://www.nerddinner.com/ for a decent example, as well as a free chapter in the Professional ASP.NET MVC 1.0 book that covers the code.

• Change is hard, for all of us. In the DOS days we used the MTF Menu-Table-Form pattern.

  MVC has been around for a long time now and there is a flavor for all major languages used in internet programming.

  Once you use MVC for a while you will probably not want to go back. It provides for code separation and reuse. I have used RoR, Django and ASP.NET MVC and the MVC pattern made my development.

  I would encourage you to keep at it! Buy a book or find a mentor.

• A more highly factored / layered design is always harder to wrap your head around initially - the payoff only comes once that happens. The advantage is that now you have clearly defined places where to put what; while being forced to stick to a predetermined separation of concerns seems onerous at first, the predictability of the code structure it makes things much easier to maintain later.

• Well, it is certainly popular. If you are doing RoR, don't fight the paradigm, go with it, that is the whole point of RoR.

  If you are in a position of defining your paradigm, the fact of the matter is that MVC tends to just be MV. A Controller according to some advocates of the pattern is intended more in the case of multiple views, which is almost always not the case in a given project (although the data may ultimately end up being viewed very differently in a different context within the enterprise). Depending on the GUI though, a separate controller can help the testability of the code (were the controller acts as the class under test, and the GUI component just hits the methods under test in the most minimal way possible).

  MVC originated with the SmallTalk crowd, which more recently got into a Morphic pattern (where the object displays itself via an inner class which subclasses the relevant GUI components). That isn't a difficult way to do HTML stuff for sure, because the html can't effectively be given to designers.

  Personally if I really am going from scratch, I prefer a Presentation pattern (I've seen it called that, but I can't find the reference now) where the view and data binding is put into a presentation class. The power of the pattern comes if the the presentation of the whole screen is made up of different presentations of portions of the data. In plain boring business apps (the kind I tend to write) bits of data (say an address) tend to get displayed on a lot of screens, so it helps to be able to chunk and reuse the gui presentation components.

  But these days, you really need to think carefully if you need to do it from scratch, at least in good old boring data display and manipulation applications. There is a lot out there, and if you use a tool, you should go with its pattern. Fighting the tool is counterproductive.