Marnen Laibow-Koser wrote in post #955794: >> 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?
Point taken. I was trying to illustrate that the separation of these tiers is beginning to blur somewhat. It's becoming a lot more common these days for applications to stand on their own much of the time while depending on external services for specific things. As opposed to relying solely on the server-side to persist state and manage the back-end. >> 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. :) Of course, design practice matters to developers. The point I was, unsuccessfully, attempting to make here is that good design practice, is good design practice, no matter what you call the organization of your application. And, that in today's diverse environments it's often required, or useful, to combine multiple patterns and architectures to provide a great user experience. The only thing I take issue with is the labeling "two-tier, three-tier, multi-tier, MVC, etc." Rather than attempt to fit my application in some predetermined architecture, I view it all as application code. Some of it runs primarily as a client, some provide services, clients sometimes communicate with other clients, servers talk to servers. These lines, we call "tiers" are blurring together. I don't mean to say that design doesn't matter. In fact I'm saying the opposite. Design matters more when the lines between what makes a server a server, and client a client, start to blur. -- 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.
