Harmedia wrote in post #955752: > For an enterprise project a small section is on 3 tier architecture > and intergrating RoR into it. I have researched RoR and found that as > standard it uses MVC which is a similar architecture except MVC allows > the client to interact directly with the database. I was wondering > however, is the "MVC" that I've read about different to the 3 tier > architecture or is it a 3 tier system within a 3 tier system? Sorry if > it sounds a really stupid question. Also from my research I've > detained that the RoR would be most suited to the server level of the > 3 tier architecture, does this sound correct?
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. Rails is based on an old and established design pattern (a sort of compound, or meta-design-pattern) called Model-View-Controller. MVC is not really directly related to the "tier" based architecture you mentioned, other than it is a way to organize complex systems and separate responsibilities. 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. The goal of this pattern is to make the Model and View objects as reusable as possible. One should be able to extract the Model objects from one application and drop them, unmodified, into a completely separate application. There should be no direct dependencies on either of the other two layers. Ideally the same holds true for View objects. 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. * Does this three-tier architecture still exist (or rather is it still prominent and important)? * If so what is the nature of these systems today? 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? Not only do we have these emerging architectures like iTunes, we have an ever expanding "three-tier" design we call AJAX. In this environment the client tier is the web browser itself, running client software written in JavaScript. How is this any different than the so called "enterprise three-tier architecture?" I say it isn't really any different at all. Does that matter? At the end of the day it's all just application code. Today we employ many different architectures to provide value to our customers. All this buzzword labeling of things just confuses the issue. So I've said all that to say this... Rails is a framework created to aid in the development of web applications. It is based on an MVC design pattern for organizing code and responsibilities. Typical Rails deployments involve a web server (Apache, Nginx, etc.), a piece of software to "connect" the web server with the application server (usually Phusion Passenger, but there are other ways to do this), a "middle-ware" piece to facilitate handling of requests and responses (Rack), and finally the Rails application itself. These applications often contains client-side application code typically written in JavaScript using AJAX techniques. How you choose to break all that into "tiers" is up to you. As far as I'm concerned it's more important to understand how these fit together in order to create valuable applications for customers, than it is to attach buzzwords to them in order to appease "C" level executives. -- 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.
