In this segment, you will learn how to connect a Laravel application to a database using configuration files. You'll also get an overview of setting up the database schema and modeling data with Laravel's Eloquent ORM.
First, let's remind ourselves of the .env file used in Laravel for environment configuration. This is where we specify the database connection details. Here's an example of the database configuration in the .env file:
DB_CONNECTION=sqlite
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=database_name
DB_USERNAME=db_username
DB_PASSWORD=db_password
Let's see what each of these configurations does:
DB_CONNECTION: Specifies the type of database. Laravel supports multiple databases like MySQL, SQLite, and PostgreSQL. In this example, it’s set to SQLite, which is file-based and simpler for development.DB_HOST and DB_PORT: Define where the database server is running. For local development, 127.0.0.1 (localhost) is often used, and 3306 is the default port for MySQL. SQLite, however, doesn’t require a host or port since it’s a file-based database.DB_DATABASE: The name of the database (or the path for SQLite). For MySQL, PostgreSQL, and other server-based databases, this is the database name. For SQLite, provide a file path like database/database.sqlite.DB_USERNAME and DB_PASSWORD: The username and password used to connect to the database. SQLite doesn’t use these credentials, but they are required for MySQL or PostgreSQL.
Note: Laravel’s .env file is designed to support various database types, not just SQLite. Including settings like DB_HOST and DB_PORT allows you to switch between different database types (e.g., MySQL, PostgreSQL) by simply changing DB_CONNECTION in the .env file. This way, if you move from SQLite (for local development) to MySQL (for production), you won’t need to restructure the entire file—just update a few values. By default, the .env template includes these database settings to maintain consistency across projects, regardless of the chosen database. While SQLite ignores host, port, username, and password settings, having these fields pre-defined in the .env file provides flexibility, consistency, and prepares the application for easy database transitions.
To understand how Laravel interacts with the database, let's look at the database configuration file located at config/database.php. This file contains the database connection settings for different environments, such as mysql, sqlite, pgsql, and sqlsrv.
Here's an example of the database configuration for SQLite:
'sqlite' => [
'driver' => 'sqlite',
'url' => env('DATABASE_URL'),
'database' => env('DB_DATABASE', database_path('database.sqlite')),
'prefix' => '',
'foreign_key_constraints' => env('DB_FOREIGN_KEYS', true),
],
In this configuration, the database key specifies the path to the SQLite database file. By default, it's set to database.sqlite in the database directory. You can change this path to store the database file in a different location. We'll not modify this configuration in our practices, as the default settings are sufficient for our ToDo app.
Now, let's see how Laravel interacts with the database using Eloquent, the ORM provided by Laravel. Eloquent allows you to define models that represent database tables and interact with them using object-oriented syntax. Let's create a model for the Todo table in our database:
namespace App\Models;
use Illuminate\Database\Eloquent\Factories\HasFactory;
class Todo extends Model
{
use HasFactory;
protected $fillable = ['title', 'description'];
}
In this model, we define the Todo class that extends the Model class provided by Laravel.
The use HasFactory statement enables the factory pattern for creating model instances. Factories are used to generate fake data for testing purposes.
The fillable property specifies the columns that can be mass-assigned when creating a new Todo instance - mass assignment is the process of assigning an array of attributes to a model, like the SQL INSERT statement with multiple columns.
With the model in place, we can now interact with the Todo table in the database using Eloquent. This interaction will happen in the service layer of our application, where we'll define methods to create, read, update, and delete Todo items. Let's see how the service layer will interact with the database:
<?php
namespace App\Services;
use App\Models\Todo;
use Illuminate\Support\Facades\DB;
class TodoService
{
public function create($title, $description = null)
{
return Todo::create(compact('title', 'description'));
}
public function findAll()
{
return Todo::all();
}
public function findOne($id)
{
return Todo::find($id);
}
public function update($id, $title, $description)
{
$todo = Todo::find($id);
if ($todo) {
$todo->update(compact('title', 'description'));
}
return $todo;
}
public function delete($id)
{
return Todo::destroy($id);
}
}
In this service class, we define the following methods:
create: Creates a new Todo item in the database using the Todo::create method with the provided title and description. The compact function creates an array from the provided variables to pass as arguments to the create method.findAll: Retrieves all Todo items from the database using the Todo::all method.findOne: Retrieves a single Todo item by its ID using the Todo::find method with the provided ID.update: Updates a Todo item by its ID with the provided title and description. The Todo::update method is called on the retrieved Todo instance with the new title and description.delete: Deletes a Todo item by its ID using the Todo::destroy method.
Note, that the controller will not change much from the previous lesson, as it will still interact with the service layer to handle requests and responses. The service layer will handle the database interactions using the Eloquent model:
<?php
namespace App\Http\Controllers;
use App\Services\TodoService;
use Illuminate\Http\Request;
class TodoController extends Controller
{
protected $todoService;
public function __construct(TodoService $todoService)
{
$this->todoService = $todoService;
}
public function index()
{
$todos = $this->todoService->findAll();
return view('todos.index', ['title' => 'ToDo List', 'todos' => $todos]);
}
public function show($id)
{
$todo = $this->todoService->findOne($id);
return view('todos.show', ['title' => 'Todo Details', 'todo' => $todo]);
}
public function store(Request $request)
{
$this->todoService->create($request->title, $request->description);
return redirect('/todos');
}
public function update($id, Request $request)
{
$this->todoService->update($id, $request->title, $request->description);
return redirect('/todos');
}
public function destroy($id)
{
$this->todoService->delete($id);
return redirect('/todos');
}
}
In this controller, we inject the TodoService instance into the constructor to interact with the database. The controller methods call the corresponding methods in the service layer to handle the CRUD operations for Todo items.
This is the moment, to pause and appreciate the beauty of the MVC architecture in action, where the controller acts as the intermediary between the user interface and the database and doesn't contain any business logic. So when we move our data from the JSON file to the database, we don't need to change the controller logic, only the service layer.
Finally, we'll use the same routing logic as before to handle the requests and direct them to the controller methods:
<?php
use App\Http\Controllers\TodoController;
Route::get('/todos', [TodoController::class, 'index']);
Route::get('/todos/{id}', [TodoController::class, 'show']);
Route::post('/todos', [TodoController::class, 'store']);
Route::put('/todos/{id}', [TodoController::class, 'update']);
Route::delete('/todos/{id}', [TodoController::class, 'destroy']);
With this setup, we have successfully integrated a database into our Laravel application and defined the database schema and data models using Eloquent. The service layer interacts with the database using the Eloquent model, and the controller handles the requests and responses, following the MVC architecture.
