Robert Walker wrote in post #955831: [...] > 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.
That's an excellent point. > As opposed to > relying solely on the server-side to persist state and manage the > back-end. I think to some extent, the external services can *all* be considered the server side, in the sense that, taken as a whole, they're the remote system. But I get your point: they're different in that they are external, so we don't have the fine-grained control over them that we would have over our own box. (Grammatical note: "server side" -- noun: "on the server side" "server-side" -- adjective: "a server-side programming language" Common English practice that doesn't get taught much anymore. Pet peeve of mine. :) ) [...] > 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. Quite true. > 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. > Yes, if you can do it sensibly. > 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. Then why are you using Rails? Rails forces (OK, strongly encourages) you to fit the server-side part of your application into its predetermined architecture. I think this is a Good Thing, because I think its architecture is well designed. It's also loose enough to be generic -- a neat trick considering every application is different and has different needs. Now, if you're considering your application as the whole mess of server-side Rails, client-side JS, external Web services, native mobile apps, and whatever else, then I think this argument holds more water...but even here, we're maybe just not seeing the architectural patterns because this type of application development is in its infancy. It wouldn't surprise me if an architecture for this sort of thing started to emerge and become as much of a standard as MVC is now. > 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. Yes indeed! 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.
