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
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
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
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.