Padrões Arquiteturais em PHP: do caos ao clean code

Chega de escrever "espaguete": por que padrões arquiteturais em PHP são essenciais

Você já abriu um projeto PHP antigo e sentiu um arrepio na espinha? Quando em um único arquivo index.php estão misturados consultas SQL, HTML, lógica de negócios e orações aos deuses antigos? Se sim — você enfrentou a falta de arquitetura. Ou, pior ainda, o caos arquitetural.

Hoje vamos falar sobre como os padrões arquiteturais em PHP transformam seu código de um monte de tijolos em um edifício sólido. Isso não é teoria para seniors com 10 anos de experiência. São ferramentas que salvarão seu sono e o orçamento do projeto. Vamos analisar 4 padrões principais: MVC, Active Record, Repository e Dependency Injection. Vamos lá!

MVC (Model-View-Controller): a base de qualquer framework

Se você trabalhou com Laravel, Symfony ou Yii2 — já viu o MVC. Não é apenas uma sigla, mas uma forma de dividir o código em três áreas de responsabilidade:

\n
• Model — dados e lógica de negócios (trabalho com BD, validação).
\n
• View — exibição (HTML, templates).
\n
• Controller — processamento de requisições (elo de ligação).
\n

Veja como fica em PHP puro (sem framework):

<?php\n// UserController.php\nclass UserController {\n    public function show(int $id): void {\n        $userModel = new UserModel();\n        $user = $userModel->findById($id); // Model\n        \n        // View\n        include 'views/user_profile.php';\n    }\n}\n\n// UserModel.php\nclass UserModel {\n    public function findById(int $id): ?array {\n        $stmt = $pdo->prepare("SELECT * FROM users WHERE id = ?");\n        $stmt->execute([$id]);\n        return $stmt->fetch() ?: null;\n    }\n}\n\n// views/user_profile.php\n<h1><?= htmlspecialchars($user['name']) ?></h1>

Quando aplicar: Sempre que você tiver mais de 2 páginas. MVC é a base. Ele proporciona separação de lógica, simplifica testes e manutenção.

Dica: Não escreva SQL diretamente na View. Isso mata toda a essência do padrão. Use templates preparados (Twig, Blade) — eles escapam automaticamente a saída, protegendo contra XSS.

Active Record: simplicidade que se paga com desempenho

Active Record é quando um objeto representa simultaneamente uma linha no BD e contém métodos para trabalhar com ela. Clássico: Eloquent no Laravel ou ActiveRecord no Yii2.

Exemplo em PHP puro:

<?php\nclass User extends ActiveRecord {\n    protected string $table = 'users';\n    \n    public static function findByName(string $name): ?self {\n        return self::query()\n            ->where('name', $name)\n            ->first();\n    }\n}\n\n// Uso\n$user = new User();\n$user->name = 'João';\n$user->email = 'joao@example.com';\n$user->save(); // INSERT no BD\n\n$admin = User::findByName('Admin');\n$admin->role = 'superadmin';\n$admin->update();

Prós:

\n
• Mínimo de código para operações CRUD.
\n
• Intuitivo para iniciantes.
\n

Contras:

\n
• Violação do Princípio da Responsabilidade Única (um objeto faz tudo).
\n
• Difícil de testar — objeto fortemente acoplado ao BD.
\n
• Escalabilidade ruim para lógica complexa.
\n

Conclusão: Active Record é uma ótima escolha para protótipos, projetos pequenos e painéis administrativos. Mas para aplicações enterprise, é melhor olhar para o Repository.

Repository: abstração sobre o armazenamento de dados

Repository é uma camada entre a lógica de negócios e a fonte de dados (BD, API, arquivos). Você diz: "Me dê o usuário p