Actually this is exercise 7 and that was exercise 9.

master
Zed A. Shaw 2 years ago
parent d2b94e54e6
commit 482386c5df
  1. 36
      07-access-a-sqlite3-database/README.md
  2. 29
      09-a-full-dynamic-blog/README.md

@ -1,29 +1,35 @@
# 07: Access a SQLite3 Database # 07: Access a SQLite3 Database
Your blog would be much better if people could post comments, so you'll use a [SQLite3](https://www.sqlite.org/index.html) database to store their comments on each post. You'll also display their comments, and optionally require a login to post. You'll now learn the basics of a project named [knex.js](http://knexjs.org/) to access a [SQLite3](https://www.sqlite.org/index.html). You'll need to create a database for the next exercise that stores TODO lists, so you might want to check out the next exercise to get an idea of where this database is going.
## Model-View-Controller ## Step 1: Migrations
The "classic" web application style you're creating is called a "Model-View-Controller" (MVC) architecture. The design is separated into: To do this you'll first need to learn how to create a migration that creates your database. The documentation for migrations is in the [knex.js migrations](http://knexjs.org/guide/migrations.html) documentation. You're specifically looking at how to use `createTable` and `dropTable` in a migration.
1. Models store and manipulate the database, usually stored in a database. Your TODO list table should have the following fields:
2. Views present the information to the user and accept their input to alter the models.
3. Controller is responsible for translating and connecting the Views to the Models and controlling access.
This architecture style is kind of dated, but it is useful when you have a data storage system that is difficult to change, but you still need to present that information to users in different ways. Rather than spend months changing a database's stored procedures you'd simply write a Controller that took existing data and transformed it to match the view. 1. id - the primary id for the row. Use `table.increments('id')` to do this.
2. updated_at and created_at -- you can use `table.timestamps(true, true)` to automatically generate these.
3. completed -- This is a boolean value, but you'll find that booleans are weird in SQLite3 and are treated as integers.
4. description -- The actual text for the TODO item.
In your application you'll create a simplified MVC system like this: Once you have these think about other things you want in a TODO list and add them too. You don't need to keep making migrations for every change, just rollback this one, update it, and add more.
1. Model is a simple module that performs the queries against your database using [knex.js](http://knexjs.org/) to return plain old JavaScript objects (POJOs). ## Step 2: Test and Models
2. Views that are templates that which accept this data after being converted by controllers.
3. Controllers are simple handlers in your `Express.js` application, but if those get too large you should put them into separate modules that you import.
## The ORM Warning Next you want install the [ava](https://github.com/avajs/ava) so you can have a nice automated test runner. You'll want to study the [ava documentation](https://github.com/avajs/ava/blob/main/docs/01-writing-tests.md) and create a simple empty test to get going.
Normally in an OOP language like Java, Python, or C++ you'd want to translate the tables you get from SQLite3 and translate them to objects. This is what an Object-Relational Mapper (ORM) does. The reason these languages need this translation is their objects are distinct data types that are separate from their Arrays or Map structures. In JavaScript the objects are also the Maps so the need for an ORM is much lower. What you get from a `knex.js` query is...an object. It's 80% ready to go, and for most of your work you won't need to add any other OOP to them. Once `ava` is installed you'll use it to test a module that uses `knex` to access the database. Your module should do the basic operations normally called "CREATE, READ, UPDATE, DELETE" to get started, and then write a test for each one.
I'm mentioning this because you might run into projects that basically take `knex.js` and then overcomplicate it to give you an ORM. These ORMs end up being more work than they're worth so I would avoid them. If you desperately want to have classes and objects come out of your SQL then wait until later in the course and you'll get to use a very minimalist ORM I created that does 95% of what you need and is far easier to understand and use. ## Step 3: Test First or Test After
You have two ways you can approach the testing process:
1. Write your test based on what a function in your Model module should do, then write the code to make the test work. This is called "test first."
2. Write a function in your Model module, then write a test to make sure it's working and try to push it further. This is called "test after."
Generally I use "test first" if I've implemented this a million times before and already know how it should work. This is rare so I more often use "test after", but I work in such a tight loop that honestly it doesn't matter. In fact, anyone telling you that you have to religiously do one or other is probably the type of person who never works on anything new and only does the same thing over and over. Real people use whatever strategy works best depending on the situation.
## Learning Objectives ## Learning Objectives
You are learning how to store data in the database from your web application, but you're really learning how to use `knex.js` and how an MVC application architecture works. I recommend you reference the application in this directory heavily as you work on your own since this architecture is difficult to create "intuitively". You're mostly learning how `knex.js` and `ava` work, with a little bit about testing process and database design. You'll definitely want to look at the next exercise, and reference my solution as much as possible when you get lost.

@ -0,0 +1,29 @@
# 09: A Fully Dynamic Blog
Your blog would be much better if people could post comments, so you'll use a [SQLite3](https://www.sqlite.org/index.html) database to store their comments on each post. You'll also display their comments, and optionally require a login to post.
## Model-View-Controller
The "classic" web application style you're creating is called a "Model-View-Controller" (MVC) architecture. The design is separated into:
1. Models store and manipulate the database, usually stored in a database.
2. Views present the information to the user and accept their input to alter the models.
3. Controller is responsible for translating and connecting the Views to the Models and controlling access.
This architecture style is kind of dated, but it is useful when you have a data storage system that is difficult to change, but you still need to present that information to users in different ways. Rather than spend months changing a database's stored procedures you'd simply write a Controller that took existing data and transformed it to match the view.
In your application you'll create a simplified MVC system like this:
1. Model is a simple module that performs the queries against your database using [knex.js](http://knexjs.org/) to return plain old JavaScript objects (POJOs).
2. Views that are templates that which accept this data after being converted by controllers.
3. Controllers are simple handlers in your `Express.js` application, but if those get too large you should put them into separate modules that you import.
## The ORM Warning
Normally in an OOP language like Java, Python, or C++ you'd want to translate the tables you get from SQLite3 and translate them to objects. This is what an Object-Relational Mapper (ORM) does. The reason these languages need this translation is their objects are distinct data types that are separate from their Arrays or Map structures. In JavaScript the objects are also the Maps so the need for an ORM is much lower. What you get from a `knex.js` query is...an object. It's 80% ready to go, and for most of your work you won't need to add any other OOP to them.
I'm mentioning this because you might run into projects that basically take `knex.js` and then overcomplicate it to give you an ORM. These ORMs end up being more work than they're worth so I would avoid them. If you desperately want to have classes and objects come out of your SQL then wait until later in the course and you'll get to use a very minimalist ORM I created that does 95% of what you need and is far easier to understand and use.
## Learning Objectives
You are learning how to store data in the database from your web application, but you're really learning how to use `knex.js` and how an MVC application architecture works. I recommend you reference the application in this directory heavily as you work on your own since this architecture is difficult to create "intuitively".
Loading…
Cancel
Save