Robert Walker wrote in post #955772: [...] > My suggestions to you is this. Forget all this nonsense about "tier > architectures" and "enterprise buzzwords" that have no real value in > getting work done. Instead concentrate on how to use the tools to aid > you in building applications that provide value to your customers. > Understand what a framework is designed to do, and take advantage of it.
Agreed wholeheartedly. [...] > An oversimplification of MVC is this. The Model is responsible for > manipulating and managing data. The View is responsible for presenting > that data to users (humans). And, the Controller is the "glue-code" > responsible for retrieving data from, and sending data to the Model, and > making that data available to the View. In an ideal MVC system the Model > objects never directly interact with the View objects and vise-versa. Very well explained! I think I'll use some version of this the next time I have to explain (Rails-style, not Reenskaug-style) MVC. [...] > One problem with thinking in terms of "tiers" is that the nature of them > keeps changing. At one point you could say that you had the "server > tier" the "client tier" and some "middle-ware tier." In the past this > probably meant having some sort of client application running locally on > a user's computer like a Java applet. And then a server-side piece that > interacted with the database on the back end. > > Today, however, this is not so much the case. I can't remember the last > time I used a Java applet or a similar client-side application who's > sole purpose in life was to communicate to some server-side application. Huh? It happens all the time, both in SOA (where one server-side application exists only to mediate between the client and another server-side application) and in Ajax and mobile development (where the JavaScript or native mobile app is often just a lightweight Web service client). In fact, you make this point yourself below. Or do I misunderstand? [...] > As I see it the lines are starting to blur. Today we have things like > iTunes and the iTunes music store. Is that a "three-tier" architecture? > In a sense, sure it is. The client is iTunes and server is the iTunes > Music Store application along with the "middle-ware" to glue it all > together. Does any of this matter to the person listening to music in > iTunes, or buying music in iTunes? No. But it matters to the person trying to develop the next iTunes (or whatever). Wasn't the OP asking the question from the developer's point of view? Now, it's certainly true that what matters ultimately is the value provided to the end user. But to provide that value most efficiently, we developers have to choose some sort of design practice. Otherwise we'd still be hacking 5000-line PHP template/script/do-everything files, and breaking everything when we change one line. :) Best, -- Marnen Laibow-Koser http://www.marnen.org [email protected] -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.
