RoR Into a 3 Tier architecture - MVC function

rubyonrails-talk
1

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,

2

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 Multitier architecture - Wikipedia 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

3

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

Model–View–Controller

4

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.

5

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,

6

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.

7

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,

8

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.