The future of the Model-View-Controller architecture

A place to discuss the implementation and style of computer programs.

Moderators: phlip, Moderators General, Prelates

User avatar
JimBastard
Posts: 9
Joined: Wed Mar 19, 2008 6:55 am UTC
Location: teh internets

The future of the Model-View-Controller architecture

Postby JimBastard » Wed Mar 19, 2008 7:11 am UTC

http://en.wikipedia.org/wiki/Model-view-controller

I build all my serious web applications based on this architecture. Am I a dinosaur? What is on the horizon?

User avatar
Miles Invictus
Posts: 232
Joined: Sat Mar 31, 2007 8:32 am UTC
Location: Iowa
Contact:

Re: The future of the Model-View-Controller architecture

Postby Miles Invictus » Wed Mar 19, 2008 8:11 am UTC

I used to work for a company that used MVC for damn near everything, so you certainly aren't alone. If MVC satisfies your needs, why worry about being behind the times? It's not like architectures have a shelf life or anything.

To be totally honest, I don't know what's on the horizon, either.

User avatar
segmentation fault
Posts: 1770
Joined: Wed Dec 05, 2007 4:10 pm UTC
Location: Nu Jersey
Contact:

Re: The future of the Model-View-Controller architecture

Postby segmentation fault » Wed Mar 19, 2008 12:58 pm UTC

i know whats on the horizon...

more buzzwords.
people are like LDL cholesterol for the internet

daydalus
Posts: 76
Joined: Thu Aug 30, 2007 4:05 pm UTC

Re: The future of the Model-View-Controller architecture

Postby daydalus » Wed Mar 19, 2008 2:02 pm UTC

Should this go in Coding?

I don't see MVC going away, although I see the View and Control portions getting more tightly wound. Dynamic, flashy websites already couple the buttons with the fireworks. This trend will continue with new technologies like Microsoft Silverlight, etc. The data Model, however, will stay abstracted and disconnected for a long time to come.

User avatar
EndangeredMassa
Posts: 46
Joined: Wed Apr 25, 2007 7:16 pm UTC

Re: The future of the Model-View-Controller architecture

Postby EndangeredMassa » Wed Mar 19, 2008 5:44 pm UTC

MVC is still very much alive. In fact, in the .NET world, it's just coming into play with the new MVC architecture.

You should always try to separate your Model from your View+Control anyway. If you happen to go a step further and have a separate View and Control, then more power to you.

As for aging technologies, if it makes sense to use SPARC assembly to solve a problem, then do it. If it makes sense to use OO or functional programming, then do it. It doesn't really matter if the technology is old or not. As long as you can find people to maintain it (which is slightly related to how old the technology is, but not necessarily significantly), then you're fine.

mrkite
Posts: 336
Joined: Tue Sep 04, 2007 8:48 pm UTC

Re: The future of the Model-View-Controller architecture

Postby mrkite » Wed Mar 19, 2008 6:25 pm UTC


User avatar
bridge
Posts: 195
Joined: Sun Feb 03, 2008 2:24 pm UTC
Location: Zurich < x < Rome

Re: The future of the Model-View-Controller architecture

Postby bridge » Thu Mar 20, 2008 7:48 am UTC


MVC introduces some overhead what a surprise!
Considering how fast you can build web apps it's worth this price anyway (in most of the cases)

My commendation is Seaside (comes directly from Xerox in some sense)
Screencast: How to Build a Blog in 15 Minutes with Seaside
Really simple example
Excuse my Super Mario accent

UchihaJax
Posts: 12
Joined: Thu Sep 06, 2007 7:37 pm UTC

Re: The future of the Model-View-Controller architecture

Postby UchihaJax » Fri Mar 21, 2008 4:20 am UTC

I don't think you'll ever really make MVC that obsolete as it's a programming paradigm that focuses on:

Showing something to the user
Allowing the user to control that display and perform commands
Binding the data inside the interface into a model which can be pushed around to do other things

I don't think we're going to stop doing that or find a different means of achieving it, unless we invent: Cheeseburger -> Hands -> Ingredients but that's just MVC with different names. New web technology is mainly attempting to make the web as seamless and responsive a local application and MVC is also a highly effective pattern to use when developing local applications.

darren
Posts: 188
Joined: Fri Feb 08, 2008 5:37 pm UTC

Re: The future of the Model-View-Controller architecture

Postby darren » Sun Mar 23, 2008 8:22 pm UTC

Design patterns are for blub programmers. Real men use continuations for UI.

User avatar
Xanthir
My HERO!!!
Posts: 5426
Joined: Tue Feb 20, 2007 12:49 am UTC
Location: The Googleplex
Contact:

Re: The future of the Model-View-Controller architecture

Postby Xanthir » Sun Mar 23, 2008 9:18 pm UTC

I doubt anything substantially different will ever emerge. MVC is basically just "Keep stuff separate so you can maintain it, jackass!"

Where we apply the separation obviously will change as higher-level languages emerge (aided by smarter tools which do more automatic code generation), but the idea is at the very core of maintainable programming.
(defun fibs (n &optional (a 1) (b 1)) (take n (unfold '+ a b)))

User avatar
davean
Site Ninja
Posts: 2498
Joined: Sat Apr 08, 2006 7:50 am UTC
Contact:

Re: The future of the Model-View-Controller architecture

Postby davean » Mon Mar 24, 2008 1:52 pm UTC

Xanthir wrote:I doubt anything substantially different will ever emerge. MVC is basically just "Keep stuff separate so you can maintain it, jackass!"

Where we apply the separation obviously will change as higher-level languages emerge (aided by smarter tools which do more automatic code generation), but the idea is at the very core of maintainable programming.


Well, there is functional reactive programming ...

There already ARE notably different ones.

User avatar
Xanthir
My HERO!!!
Posts: 5426
Joined: Tue Feb 20, 2007 12:49 am UTC
Location: The Googleplex
Contact:

Re: The future of the Model-View-Controller architecture

Postby Xanthir » Mon Mar 24, 2008 2:01 pm UTC

I choose to exploit the open-endedness of my comment to say that this is included in the "higher-level languages" category, as my initial googling seems to show that frp is essentially just automagically adding triggers to every input that reevaluate the functions that use that input on a change.
(defun fibs (n &optional (a 1) (b 1)) (take n (unfold '+ a b)))

User avatar
davean
Site Ninja
Posts: 2498
Joined: Sat Apr 08, 2006 7:50 am UTC
Contact:

Re: The future of the Model-View-Controller architecture

Postby davean » Mon Mar 24, 2008 9:49 pm UTC

Xanthir wrote:I choose to exploit the open-endedness of my comment to say that this is included in the "higher-level languages" category, as my initial googling seems to show that frp is essentially just automagically adding triggers to every input that reevaluate the functions that use that input on a change.


Then I challenge your view of what MVC is and point you at it's definition.

User avatar
Xanthir
My HERO!!!
Posts: 5426
Joined: Tue Feb 20, 2007 12:49 am UTC
Location: The Googleplex
Contact:

Re: The future of the Model-View-Controller architecture

Postby Xanthir » Tue Mar 25, 2008 12:43 am UTC

All right.

MVC is really quite simple. You merely separate your data (model) from the presentation (view) from the logic (controller). The exact details are far from important, and in fact this pattern is implemented in many different ways.

FRP is, as I said, essentially a way to implicitly place triggers that look for data changes and rerun functions that depend on that data. All this does is abstract a piece of the Controller by implementing a form of the Observer pattern for you. If you were to do this manually, it would still conform just fine to MVC.

When and how you grab your data is clearly part of the program logic. It doesn't depend on properties of the data itself. Thus, this fits into the MVC pattern just fine.

Depending on how FRP is implemented, this may be listed as a property of the data, however. We may, frex, mark some data as 'volatile' or somesuch, indicating that it needs the dataflow triggers that frp implicitly provides, while other data is 'stable' and will have its dataflow implemented manually. This also obeys the architecture - you're merely abstracting in a slightly different direction.

As I said, higher-level constructs may change *where* we draw the lines between M, V, and C, but it doesn't change the nature of the line drawing. Data, logic, and presentation form a fundamental trichotomy in maintainable programming.
(defun fibs (n &optional (a 1) (b 1)) (take n (unfold '+ a b)))

mrkite
Posts: 336
Joined: Tue Sep 04, 2007 8:48 pm UTC

Re: The future of the Model-View-Controller architecture

Postby mrkite » Wed Mar 26, 2008 9:37 pm UTC

Xanthir wrote:MVC is really quite simple. You merely separate your data (model) from the presentation (view) from the logic (controller).


As I said earlier, MVC is ill-suited for the web. Mainly because the very nature of the web already makes this distinction. Using something like CakePHP adds complexity without adding any real benefits.

Look at any MVC framework for the web and the controller is almost completely redundant, it uses the URL to determine which action to take. That's Apache's job. All you're doing is rolling up all your actions into one big file, instead of having separate files for separate actions.

Second, since the model cannot remain in memory (like a typical application) the controller also has to provide callbacks for the view to request the data it needs.

You inevitably end up with the same thing you get without an MVC framework. The view does all the work, calling library functions provided by the controller to get at the data it needs. No different from having Apache call the proper php file based on the url, and having those files call library functions provided by php to request the data it needs (usually through something like PEAR:MDB2).

User avatar
ash.gti
Posts: 404
Joined: Thu Feb 07, 2008 1:18 am UTC
Location: Probably a coffee shop.

Re: The future of the Model-View-Controller architecture

Postby ash.gti » Wed Mar 26, 2008 9:53 pm UTC

mrkite wrote:As I said earlier, MVC is ill-suited for the web. Mainly because the very nature of the web already makes this distinction. Using something like CakePHP adds complexity without adding any real benefits.


What things like CakePHP are designed to do is give you a single, simplified set of functions/tools to help you.

mrkite wrote:Look at any MVC framework for the web and the controller is almost completely redundant, it uses the URL to determine which action to take. That's Apache's job. All you're doing is rolling up all your actions into one big file, instead of having separate files for separate actions.


Yes, but apache isn't traditionally smart enough to load dynamic content. And the reason you clump similar actions into controllers is simplify the overall process into a way that is fast. A single controller might have 5 or 10 actions related to it, but there also might be 5 controllers. It would be stupid to put all the controllers in 1 file, thats a lot to parse if you want the system to be quick.

In systems like Ruby on Rails and CakePHP the file naming based off routing does more help cut down clutter.

mrkite wrote:You inevitably end up with the same thing you get without an MVC framework. The view does all the work, calling library functions provided by the controller to get at the data it needs. No different from having Apache call the proper php file based on the url, and having those files call library functions provided by php to request the data it needs (usually through something like PEAR:MDB2).


The whole reason for the separation of layers is code maintainability. If your doing database calls in the same place your doing the html structure then you might run into problems if someone asks you to complete redesign the layout of the website. But if they are completely separate you won't loose any of your control logic by accident.

All they are for is simplifying things for the developers.

If you can make a link in half the number of characters why wouldn't you?
If you can separate your logic from the view and your model from your controller why not? It lets you adapt to things a lot easier. Its purely related to being flexible. If all of a sudden someone made this super new awesome database system that would make you whole application 100% faster then in a system based off of MVC your simply changing your Model component leaving the other two sections completely untouched. Where as if your model is IN your view or controller then you have to dig through a lot MORE before you can make that sort of transition.
# drinks WAY to much espresso

User avatar
Xanthir
My HERO!!!
Posts: 5426
Joined: Tue Feb 20, 2007 12:49 am UTC
Location: The Googleplex
Contact:

Re: The future of the Model-View-Controller architecture

Postby Xanthir » Wed Mar 26, 2008 9:57 pm UTC

You're making some bad assumptions, which are coloring your views.

The file on the server isn't the view, it's the controller. Essentially, it's a function called by apache. It returns a bytestream, which apache then sends to the client. The *view* is what the user sees when the browser renders the bytestream as a page.

This is usually a better way to think about things when you're using server-side programming.
(defun fibs (n &optional (a 1) (b 1)) (take n (unfold '+ a b)))

User avatar
Mr. Heavy
Posts: 25
Joined: Tue Mar 25, 2008 11:53 pm UTC
Location: Long Island, NY
Contact:

Re: The future of the Model-View-Controller architecture

Postby Mr. Heavy » Wed Mar 26, 2008 11:18 pm UTC

ash.gti wrote:The whole reason for the separation of layers is code maintainability. If your doing database calls in the same place your doing the html structure then you might run into problems if someone asks you to complete redesign the layout of the website. But if they are completely separate you won't loose any of your control logic by accident.

This isn't the only reason. Proper delegation of responsibilities in multi-person teams, in which people have distinct jobs to perform, is very important as well; for example, by exposing only explicitly templated objects to your designers, you can ensure they don't do things they're not supposed to like trying to circumvent the developers of the business logic and throwing in some completely ridiculous and insecure inline SQL statements. (It sounds completely convoluted, but it happens a lot. Do not trust web guys to be DBAs on enterprise applications.)


Return to “Coding”

Who is online

Users browsing this forum: No registered users and 5 guests