Мой первоначальный план с этим блогом состоял в том, чтобы попробовать писать ежедневные отчеты. Однако дни могут быть напряженными, и я признаю, что часто просто ем-сплю, когда возвращаюсь домой. Извинения.

Неделя 3 ознаменовала конец первого цикла, строго ориентированного на серверную часть, и представила новую концепцию: базы данных.

Понедельник был продолжением проекта MVC поваренной книги, в котором мы добавили новые функции, такие как возможность удалять и сохранять рецепты с известного кулинарного веб-сайта. Следующие 2 дня были основаны на аналогичной задаче: разработать приложение для доставки еды, способное отображать 2 разных меню в зависимости от статуса пользователя (менеджер или курьер, защищенный паролем) и способное записывать клиентов, принимать/удалять заказы… Это означало, что обязательство создать несколько моделей, репозиториев, контроллеров и представлений. Упражнение было отличным для понимания принципа единой ответственности, главного в ООП, согласно которому каждый модуль или класс должен нести ответственность за одну часть функциональности, предоставляемой программным обеспечением.

Возьмите приложение для доставки еды: классы Meal, Employee и Customers несут ответственность только за свою собственную информацию и не должны быть связаны каким-либо образом. Единственный способ соединить их — через класс Order, выступающий в качестве перекрестка между ними: новый заказ состоит из еды, выбранной покупателем и доставленной сотрудником.

Конечно, но основная трудность упражнения заключалась в том, чтобы понять преимущества принципа единой ответственности и создать гармоничные отношения между различными контролерами. Легко начать смешивать обязанности и все испортить. Это также было отличным введением в новую область, увиденную в четверг в пятницу: базы данных.

Что такое данные?

Я не уверен, почему, но я немного беспокоился о базах данных. Единственные проблески, которые у меня были, были основаны на файлах CSV. Я не чувствовал, что они очень удобны для пользователя, и я немного потерялся между терминами, которые обычно встречаются в Интернете: SQL, Postgre, NoSQL, MongoDB, постоянство… Какой лабиринт!

Поэтому SQLite был облегчением. Структура данных довольно проста, а сам синтаксис не может быть яснее. Прокричите свои инструкции на экран, и вы сразу же получите необходимые данные.

SQL (язык структурированных запросов) основан на системе реляционных баз данных, что означает, что данные организованы в таблицы, связанные друг с другом. Как и в ruby, каждый объект (или таблица) отвечает за свои спецификации. Приведенный выше пример показывает, что если Водителю обязательно нужна машина, это не значит, что машине нужен водитель. Автомобиль по своей природе всего лишь автомобиль.

Большой заслугой SQLite является его понятный синтаксис:

SELECT * FROM driver WHERE name = "bob";

Эта короткая строка даст массив всех водителей, чье имя соответствует боб. Теперь вы также можете искать элементы по идентификатору. Следуя функциям CRUD, мы можем сделать наши данные постоянными в файлах sqlite и избавиться от наших CSV. О да!

Я понятия не имею, чем другие типы баз данных будут отличаться, но SQLite очень помог сделать вещи более доступными.

На четвертой неделе мы представим Active Record, а затем, наконец, перейдем к Front-End!