# Architecture Overview

https://dev.wisecp.com/es/architecture-overview

One request enters. One dispatcher decides whether it is a page or a mutation, and the answer comes back as HTML or as JSON. Everything else is a layer serving that sentence.

## Overview

WISECP is a custom MVC framework, not a general-purpose one wearing a costume. It has controllers, models and views in the usual sense, plus two pieces of its own. *Operations* are the only way data changes. *Hooks* are how anyone outside the core takes part.

Reading a feature usually means reading four files. The controller answers the address and the model fetches the rows. The template turns them into markup, and the operation trait changes them. Once that shape is familiar the codebase stops being large and starts being repetitive, which is the point.

## Structure

### The Request Flow

```bash
index.php
  └─ bootstrap.php   constants, autoloader, configuration, session, language
      └─ Bootstrap::run()   address -> route -> controller file + params
          └─ {controller}->index(), or ->main() when there is no index()
              ├─ the request carries `operation`  -> operation method -> JSON
              └─ anything else                    -> page_{name}()    -> HTML
```

The fork in the middle is the thing to remember. The operation name is read from the request, not from the verb, so either verb can carry it. What it decides is that no page will be built. A request that names an operation never produces a page, and a page method never writes. That separation makes permissions, demo mode and error formatting decidable in one place instead of in every screen.

### The Layers

- **Router**: Turns an address into a controller and its parameters. Routes are translated per language, so the same page has a different path in each one.
- **Controllers**: The base every controller extends. It loads the matching model, exposes the view, collects the data a template will receive and dispatches operations.
- **Models**: The base every model extends. Database access lives here and nowhere above it.
- **View**: Picks the template directory and builds the output from a template and the collected data.
- **Operation**: The object handed to an operation method. It carries the demo guard, the hook helper and the JSON response.
- **Hook**: The extension surface. Modules, themes and installation-level rules all attach here.

### Three Surfaces, One Application

The admin panel, the public website with the client area, and the scheduled command line all run the same core. They differ in which controllers answer, which templates are used and which session is in play. A helper written for one is available to the others. That is why business rules belong in helpers rather than in a controller.

## Pitfalls

> **The admin and client sides are separate code paths**
> 
> They often do the same thing through different files. A change made on one side is not automatically true on the other. When you fix a behaviour, check whether its twin exists elsewhere.

> **Queries belong in the model**
> 
> A query written in a controller or a template works. Later it becomes the reason a page cannot be reused, cached or called from the command line. Put it in the model even when it is one line.

## Related Articles

- [Bootstrap and Autoloading](https://dev.wisecp.com/en/bootstrap-and-autoloading)
- [Controllers and Routing](https://dev.wisecp.com/en/controllers-and-routing)
- [The Model Layer](https://dev.wisecp.com/en/the-model-layer)
- [Operations](https://dev.wisecp.com/en/operations)
- [How Hooks Work](https://dev.wisecp.com/en/how-hooks-work)