Video #1 - Associations

This is the first course in a Coursera Specialization track involving Web Application Architectures. This course will give you the basic background, terminology and fundamental concepts that you need to understand in order to build modern full stack web applications. A full stack web developer is familiar with each "layer" of the software technologies involved in a web application, including data modeling and database technologies, the web server environment and middleware components, network protocols, the user interface and basic visual design and user interaction concepts.
In this course we will learn by doing. We will start by learning the major components of web application architectures, along with the fundamental design patterns and philosophies that are used to organize them. You will build and continually refine a fully functional full-stack web application as we progress through the modules in this course. Along the way you will be exposed to agile software development practices, numerous tools that software engineers are expected to know how to use, and a modern web application development framework.
This course is also available in Spanish. To join the Spanish version, visit this page: https://www.coursera.org/learn/apliweb.

審閱

AJ

very useful course but their is only one problem that i face ruby on rails is not installing properly .

AB

Apr 21, 2020

Filled StarFilled StarFilled StarFilled StarFilled Star

The course is good but discussion forum needs active support anyway thanks to professor Greg Heileman.

從本節課中

Module #3 - Managing Data

A successful web application provides information t

o users that is (1) useful, and also (2)
easy to access and understand. This information is
often collected from users, as well as
from other information sources, and must be stored
in a manner that allows it to be
manipulated by the web application. The typical app
roach is to store this data in a
relational database. In this module you will learn
some basic concepts associated with
modeling the data in a web application, including h
ow to specify the relationships between
various data entities. We will also investigate ho
w to hook a web application up to a back-
end data store, along with good design techniques t
hat will make it easier to use the data in
your web applications by maintaining consistency th
roughout the entire web stack.

教學方

Greg Heileman

Manel Martínez-Ramón

腳本

[MUSIC] When we talked about relational databases, we discussed one-to-many, and many-to-many relationships. Let's talk about how we specify these relationships in our Rails models. Let's quickly review what the one-to-many relationship looks like in an ERD. In this model one post can have many comments. Because of this, the foreign key is on the comment side of this relationship. Here's the many-to-many relationship we previously discussed, and recall how we implemented it using a join table. Recall that a join table only stores the foreign keys associated with each side of the many-to-many relationships. Here's one we did not discuss previously. It's a one-to-one relationship. In this example, I'm showing in the data model that we'd like to enforce a constraint that each customer can have only one account and that each account can belong to only one customer. Notice that there's no crow's foot on the relationship drawn between these two entities and that I'm placing the foreign key inside the account entity. I could just as easily have placed the foreign key on the other side of this relationship, that is, the ID of an account within the customer entity. However, it seems more natural to think of the account as belonging to the customer rather than the customer belonging to the account. We've spent a lot of time understanding how the Active Record design pattern works, so we know now that by using the scaffold generator in our blog application, we've got that thing pre-wired for us inside our app. This meant that we've got a database that's already set up, ready to store posts and comments, and now, in fact, users, and that we had a connection that was established to the database that created this virtual object store for us. In addition, the Post and Comment objects were set up through a object relational mapping, and this really provides the M, the model portion of the model view controller architecture. Now one thing is missing. Comments are not automatically associated with posts when we create comments. Recall that when we created each comment, we had to inspect the database and find the ID of the post it belongs to, and then we manually entered this ID when we created the comment. We can't expect users to do something like this. So far we've made the connection between posts and comments in the database, because a post_id is stored with each comment. But the models themselves are not aware of this connection. We need to figure out how to automatically add the ID of the post as a foreign key in the comment record. We're going to do this by adding associations in our models. To make our models in Ruby fully functional, we need to add these associations. In other words, each post needs to know the list of comments associated with it, and each comment needs to know which post it belongs to. To help you understand how to specify these associations in Rails, let's take another look at the ERD models I showed you at the beginning of this video. Looking at this one-to-one relationship, you would say that a customer has one account and that an account belongs to one customer. Because the foreign key is stored in the account, I'm using the term belongs to here. For the many-to-one relationship, we'd say that a post has many comments and that a comment belongs to a post. Again, the foreign key is on the belongs to side. Finally, for the many-to-many relationship, we'd say that a person has and belongs to many addresses and likewise we'd say that an address has and belongs to many people. The foreign keys in this case are in the join table, addresses_people. The ActiveRecord module contains a set of class methods of tying objects together through their foreign keys, and guess what? They use exactly the same terminology that I just introduced when discussing the various types of associations. Specifically, in the following table, I provide the class methods that should be called within each model for each type of an association. So on the first row here you see one-to-one. In the model without the foreign key, you use the has_one declaration, and on the model with the foreign key, you use the belongs_to. For the second row, the many-to-many relationship, the model without the foreign key has the has_many declaration. Model with the foreign key, belongs_to. And finally, if you've got a many-to-many relationship, then the models that are on either side of the join table just use the has_and_belongs_to_many declaration. Let me show you how to do this in the next video in our blog application.