Aplicação Web CRUD com Login, Sessão e Modelagem Própria

O objetivo do trabalho é transformar o template em uma aplicação real de outro domínio. O aluno deverá demonstrar domínio de autenticação, sessão, CRUD, modelagem de banco de dados, relacionamento entre tabelas, validações, organização em camadas e regras de negócio.

A aplicação final não deve ser apenas uma troca de nomes. Ela precisa ter decisões próprias de modelagem, fluxos de uso coerentes e funcionalidades que façam sentido para o tema escolhido.

1. Usar PHP puro com MySQL, partindo do template fornecido.
2. Implementar login, logout e controle de sessão.
3. Bloquear páginas internas para usuários não autenticados.
4. Criar uma entidade principal diferente de Pokémon.
5. Implementar CRUD completo da entidade principal: criar, listar, editar, excluir e buscar por ID.
6. Modelar um banco de dados com pelo menos 4 tabelas.
7. Ter pelo menos um relacionamento 1:N.
8. Ter pelo menos um relacionamento N:N com tabela intermediária.
9. Usar Repository para todo acesso ao banco. As páginas não devem conter SQL diretamente.
10. Usar Entity para representar os objetos principais da aplicação.
11. Implementar validações de entrada e mensagens claras de erro/sucesso.

O projeto deve conter pelo menos um relacionamento muitos-para-muitos. Esse relacionamento deve ser representado por uma tabela intermediária e também deve aparecer na interface.

Exemplos:

• livro, autor, livro_autor
• evento, participante, evento_participante
• playlist, musica, playlist_musica
• pedido, produto, pedido_item
• receita, tag, receita_tag

A entidade principal deve permitir o cadastro de uma imagem.

Exemplos: capa de livro, foto de produto, cartaz de evento, imagem da receita, capa de álbum ou avatar de personagem.

• Aceitar apenas formatos como jpg, png ou webp.
• Definir limite máximo de tamanho do arquivo.
• Salvar o arquivo em uma pasta como uploads/.
• Salvar no banco apenas o caminho ou nome do arquivo.
• Exibir a imagem na listagem ou na página de detalhe.
• Permitir trocar ou remover a imagem.

Os recursos abaixo podem ser usados para diferenciar projetos mais completos:

• Cadastro de novo usuário.
• Validação de cadastro por email usando token.
• Recuperação de senha por email ou link de redefinição.
• Edição de perfil com avatar.
• Permissões de usuário comum e administrador.
• Soft delete com campo excluido_em.
• Tela de lixeira para restaurar registros excluídos.
• Favoritos ou coleção pessoal por usuário.
• Histórico de ações em tabela de auditoria.
• Campos calculados, como total de pedido, média de nota ou dias restantes para um evento.

Parte das regras de negócio deve ficar dentro das entidades, não apenas nas páginas ou repositories. O objetivo é que o objeto proteja o próprio estado.

Exemplos:

• $evento->publicar() impede publicar evento sem data.
• $livro->marcarComoEmprestado() impede emprestar livro já emprestado.
• $produto->baixarEstoque($quantidade) impede estoque negativo.
• $receita->publicar() exige título, categoria e pelo menos um ingrediente.

• O projeto deve ser versionado em um repositório no GitHub.
• Todos os integrantes do grupo devem apresentar commits próprios no histórico do repositório.
• Os commits devem demonstrar participação real no desenvolvimento, não apenas alterações simbólicas no final.
• Não será considerado adequado apresentar poucos commits com muitas alterações acumuladas de uma só vez.
• O histórico deve mostrar commits distribuídos ao longo do processo de desenvolvimento, com antecedência mínima de uma semana em relação à apresentação.
• A avaliação será presencial.
• Turma DS313: avaliação em 2 de junho.
• Turma DS315: avaliação em 5 de junho.
• Durante a apresentação, haverá arguição oral sobre o código, a modelagem do banco, as decisões de arquitetura e as funcionalidades implementadas.
• Todos os integrantes devem estar preparados para explicar partes do projeto.