Through advances in leaky abstractions, we’ve managed to compress the conceptual overhead of the database so much that it needn’t feature in the introduction material for making database-backed applications. In Rails, we call that abstraction Active Record, and it falls into the category of object-relational mappers (ORM).
The chief accomplishment of Rails was to unite and cultivate a strong tribe around a wide set of heretical thoughts about the nature of programming and programmers.
But Rails takes MVC further: when you develop in Rails, you start with a working application, each piece of code has its place, and all the pieces of your application interact in a standard way.
Every piece of knowledge in a system should be expressed in one place.
Rails was extracted from a real-world, commercial application. It turns out that the best way to create a framework is to find the central themes in a specific application and then package them in a generic foundation of code. When you’re developing your Rails application, you’re starting with half of a really good application already in place.
Over the years since Rails was introduced, the term agile has gone from being relatively unknown to being overhyped, to being treated as a formal set of practices, to receiving a well-deserved amount of pushback against formal practices that were never meant to be treated as gospel, to a return back to the original principles.
Agile Manifesto Values:
The Rails development process isn’t driven by documents. You won’t find 500-page specifications at the heart of a Rails project. Instead, you’ll find a group of users and developers jointly exploring their need and the possible ways of answering that need. You’ll find solutions that change as both the developers and the users become more experienced with the problems they’re trying to solve. You’ll find a framework that delivers working software early in the development cycle. This software might be rough around the edges, but it lets the users start to get a glimpse of what you’ll be delivering.
In this way, Rails encourages customer collaboration. When customers see how quickly a Rails project can respond to change, they start to trust that the team can deliver what’s required, not just what’s been requested. Con- frontations are replaced by “What if?” sessions.
The agile way of working that Rails encourages is tied to the idea of being able to respond to change. The strong, almost obsessive, way that Rails honors the DRY principle means that changes to Rails applications impact a lot less code than the same changes would in other frameworks. And since Rails applications are written in Ruby, where concepts can be expressed accurately and concisely, changes tend to be localized and easy to write. The deep emphasis on both unit and system testing, along with support for test fixtures and stubs during testing, gives developers the safety net they need when making those changes. With a good set of tests in place, changes are less nerve-racking.
The Rails team has chosen not to include plenty of features—such as user authentication—in the Rails framework itself. That doesn’t mean that these features aren’t important, but it generally does mean that no single solution is the obvious default for Rails users.
For all but SQLite 3, you’ll need to install a database driver—a library that Rails can use to connect to and use with your database engine. This section contains links to instructions to get that done.
In Rails, we call methods that make it easier to write templates helpers.
Back in 1979, Trygve Reenskaug came up with a new architecture for devel- oping interactive applications. In his design, applications were broken into three types of components: models, views, and controllers.
The model is responsible for maintaining the state of the application. Some- times this state is transient, lasting for just a couple of interactions with the user. Sometimes the state is permanent and is stored outside the application, often in a database.
A model is more than data; it enforces all the business rules that apply to that data.
The model acts as both a gatekeeper and a data store.
In a Rails application, an incoming request is first sent to a router, which works out where in the application the request should be sent and how the request should be parsed. Ultimately, this phase identifies a particular method (called an action in Rails parlance) somewhere in the controller code. The action might look at data in the request, it might interact with the model, and it might cause other actions to be invoked. Eventually the action prepares information for the view, which renders something to the user.
The create() method handles user requests. In this case, it finds the current user’s shopping cart (which is an object managed by the model). It also asks the model to find the information for product 2. It then tells the shopping cart to add that product to itself. (See how the model is being used to keep track of all the business data? The controller tells it what to do, and the model knows how to do it.)