RoR Into a 3 Tier architecture - MVC function

Hey,

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?

Thanks alot for any help,

Hey,

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.

No, he can only interact by going through the Controller and the Model

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?

I think the MVC concept has pretty much superseded 3-tier for web applications.

Using http://en.wikipedia.org/wiki/Multitier_architecture as a reference.
I would say that approximately the Data tier maps to the database
driver (MySQL or whatever). In Rails the Logic tier is further
divided into the Model, which handles business logic and the
Controller which handles requests from the user and makes data
available for the View. The Presentation layer more or less maps to
the View. Though possibly it would be better to show the controller
riding the dividing line between the presentation layer and the logic
tier.

No doubt others will have different views. To be honest I don't think
it matters much.

Colin

I never heard rails MVC and 3-tier architecture used in the same
sentence before in all my readings. i just thinking of MVC as a design
pattern separating areas of concerns.

I had to look at the definition for 3-tier architecture and it said
this about the two:

At first glance, the three tiers may seem similar to the
model-view-controller (MVC) concept; however, topologically they are
different. A fundamental rule in a three tier architecture is the
client tier never communicates directly with the data tier; in a
three-tier model all communication must pass through the middleware
tier. Conceptually the three-tier architecture is linear. However, the
MVC architecture is triangular: the view sends updates to the
controller, the controller updates the model, and the view gets
updated directly from the model.

Multitier architecture
http://en.wikipedia.org/wiki/Multitier_architecture

Model–View–Controller
http://en.wikipedia.org/wiki/Model–View–Controller

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.

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

Best,

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

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.

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. :slight_smile: )

[...]

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 wrote in post #955845:

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.

I use Rails because I also believe in the adage of "decisions are bad."
The fewer I have to make as a developer the happier I am. "Everything
has a place, and everything is in its place." This is a gross
exaggeration, obviously, but is intended to present an ideology.

Speaking of pet peeves; I suppose my responses are a side effect (or is
that side-effect? Ahh! Who really cares?) of too much time in enterprise
application development. I feel inundated with an insane number of
mostly meaningless acronyms and buzzwords.

I fully recognize the need for both creating, and putting names to,
design patterns. But, there are limits to how much of that I can stand.