Theory
The portal is a pile of scripts
The event portal works, but look at it honestly: login.php, search.php, register.php, each a mix of database code, HTML, and logic tangled together. Add 20 more pages and it becomes unmaintainable: change the header and you edit 30 files; find a bug and you hunt through spaghetti.
Professional teams do not build this way. They use a framework that enforces STRUCTURE. PHP's classic teaching framework is CodeIgniter, and its organising idea is MVC: a clean separation that this lesson uses to rebuild the portal properly.
Theory
MVC: three jobs, cleanly separated
MVC (Model-View-Controller) splits an application into 3 layers, each with ONE job:
- Model: the DATA layer: talks to the database, holds the registrations
- View: the PRESENTATION layer: the HTML the user sees
- Controller: the LOGIC layer: receives the request, asks the Model for data, and hands it to the View
Separation of concerns is the payoff: the designer edits Views without touching database code; you change the database in the Model without breaking pages; logic lives in Controllers, not scattered through HTML. The tangled script becomes 3 tidy, independent layers.
Theory
Setup and routing
Setup (CI4): install via Composer (or download), configure the base URL and database credentials in the config files, and run the built-in development server. CodeIgniter provides the plumbing: routing, database access, validation, sessions, so you write features, not infrastructure.
Routing maps a URL to a Controller METHOD. A request to /events is routed to (say) the Events controller's index() method; the default controller handles the home route; routes are declared in Config/Routes.php. So the URL no longer points at a physical file (events.php); it points at a controller action, and the framework wires it up. This indirection is what lets MVC stay organised.
Practical
A controller that loads a view (CI4 shape)
<?php
// app/Controllers/Events.php
namespace App\Controllers;
class Events extends BaseController {
public function index() {
// CONTROLLER: coordinate. Ask a Model for data (simplified here):
$data["events"] = ["Garba Night", "Coding Contest"];
// Hand the data to a VIEW to render:
return view("events_list", $data);
}
}
// A request routed to /events runs index(), which renders the view.
// The VIEW (app/Views/events_list.php) just displays $events as HTML.
// A MODEL (app/Models/EventModel.php) would fetch $events from MySQL.
?>
Quiz
In MVC, which layer is responsible for talking to the database and managing data?
- The View
- The Model
- The Controller
- The Router
Show the answer
The Model
The MODEL is the data layer: it handles database interaction and business data (fetching and saving registrations). The VIEW is presentation only (the HTML the user sees). The CONTROLLER coordinates: it receives the request, asks the Model for data, and passes it to the View, but it should not itself contain raw database code in clean MVC. The Router (not one of the 3 MVC layers) maps URLs to controller methods. Keeping these jobs separate is the whole point: data in the Model, display in the View, coordination in the Controller. Mixing them (SQL inside a View) is the anti-pattern MVC exists to prevent.
Think first
Trace a request through MVC
A user visits /events on the CodeIgniter portal. Trace the request through routing and the 3 MVC layers to the rendered page. Then tap.
Show the answer
1: Routing matches the URL /events to the Events controller's index() method. 2: Controller (Events::index) runs: it is the coordinator. 3: it asks the Model (EventModel) for the event data, which queries MySQL and returns the records: data logic lives here. 4: the controller passes that data to a View (events_list.php), which renders it as HTML: presentation logic lives here. 5: the finished HTML goes back to the browser. Each layer did exactly one job: route to controller, controller coordinates, model fetches, view displays. That clean flow, URL to route to controller to model to view, is the MVC request cycle, and reciting it is the core exam answer.
Watch out
MVC / CodeIgniter traps
SQL in the View or Controller: database code belongs in the Model; leaking it elsewhere breaks separation.
HTML in the Controller: presentation belongs in the View; controllers coordinate, they do not echo pages.
Thinking the URL is a file: in CI, routes map URLs to controller METHODS, not physical .php files.
Skipping config: base URL and database settings must be configured or the app misbehaves.
Fighting the framework: use CI's provided tools (routing, validation) rather than hand-rolling around them.
Theory
Structure in place; now its power tools
With MVC and routing, the portal is organised the professional way: data, presentation and logic cleanly separated. The final Unit 3 lesson uses CodeIgniter's built-in POWER TOOLS: its form-validation library, session and flashdata handling, file uploads, and reusable helpers and libraries, so the framework does the repetitive work you hand-coded earlier in the unit. Then Unit 4 turns to the IKS astronomy topic. The framework earns its keep next.
Summary
Key takeaways
- A framework provides structure and reusable components; CodeIgniter is a classic PHP MVC framework (CI4).
- MVC separates concerns: Model (data + database), View (presentation/HTML), Controller (logic + coordination).
- Separation of concerns makes apps maintainable: change one layer without breaking the others.
- Setup: install via Composer, configure base URL and database, run the dev server.
- Routing maps a URL to a Controller method (not a physical file); the default controller handles the home route.
- Request cycle: URL -> route -> controller -> model (data) -> view (HTML) -> browser.
- Memory hook: Model data, View display, Controller coordinates.