I understand the different roles the Model, View and Controller play in an application but how are they linked to each other, for example a simple comparison is when linking a JavaScript file with an HTML file a tag is required with a 'src' reference.
Since learning Rails I have been told they are linked, but not how.
How are the Model, View and Controller actually linked and why is a 'src' or something similar not required with MVC and specifically Rails?
Basically it's all linked through routes controllers and actions.
The routes file (routes.rb file in your_app_root/config) effectively intercepts an incoming url and maps that url to a controller/action (actually that's done by a web server like Nginx which then passes the request on to your rails app via something like Unicorn but that's another question entirely).
So for a standard HTML site set up you might have a folder called home and in that folder you might have an index.html
So when you navigate to some_url/home/index then you will get the contents of the index.html file rendered in the browser.
In RoR for this to work you will need a route defining a get request for a collection (plural or no params passed in)
It could look something like this
YourApp::Application.routes.draw do
get 'home', to: 'home#index', as: :home
# etc...
That route would connect your browser to the index action on the home controller if you navigate to some_url/home
The index action in the home controller can just be an empty action
class HomeController < ApplicationController
def index
end
end
And providing you have an index.html.erb in the app/views/home folder then you will get that file rendered automatically as ActionController translates whatever you have told it to render in to HTML, css and javascript or json or XML if you are using resource routes and the request it receives is an XML or JSON request, and sends the resulting data back to the browser
If you wanted to get some data displayed from your database then the controller action has the responsibility of obtaining that data and stuffing it into an object (an instance variable which is denoted by an @ symbol) that your view can use in an erb tag
e.g.
class HomeController < ApplicationController
def index
@some_records = SomeModel.all
end
end
This can then be used in the index.html.erb file like so
<ul>
<% @some_records.each do |rec| %>
<li> A record: <%=rec.some_method%> </li>
<% end %>
</ul>
Because you have a route you can use the routes name as a path for links and buttons to post data from the browser back to the server where the whole process starts all over again.
That's not a strict description of exactly how it all hangs together but it shou close enough to give you an idea of how it all happens
Model–view–controller is a software design pattern that organizes Rails applications. From the viewpoint of a software architect, it is an abstraction that simply provides a way to organize code. You can see the MVC design pattern in the hierarchy of classes in the Rails API, notably ActionController (controller), ActionView (view), and ActiveRecord (model), which are objects that can be subclassed to be used as components of your web application. You can also see the MVC design pattern reflected in the file structure of a Rails application, where you will find folders for models, controllers, and views. You won't see the actual code that wires together models, controllers, and views unless you dig deep into the Rails source code.
For a deeply technical introduction to the Rack middleware that ties together models, controllers, and views, you can read the RailsGuide: Rails on Rack which describes the Action Dispatcher.
The Action Dispatcher does the work of integrating the model, controller, and view objects. When you follow the Rails convention of organizing code according to the MVC design pattern, Rails does all the work of "linking" the code for you. You never actually see the code that "links" the MVC pieces together.
For a more complete explanation of MVC (and everything else that is Rails), see my in-depth article:
To understand Rails, you need to look at it from several perspectives, including software architecture.
