new ViewController

[nicozsd]

Sistema completamente novo responsável por expor views do banco de dados como recursos consultáveis via endpoints REST dedicados, com sistema de busca próprio e integração ao processo de instalação e atualização da controladora.

---

CONTEXTO

Views do banco hoje não possuem representação estruturada dentro da controladora. Toda consulta passa pelo TableController, que foi projetado para tabelas com operações de escrita. O ViewController nasce como camada exclusiva de leitura, mapeando views diretamente para endpoints consumíveis, sem herdar nem depender do fluxo de tabelas.

A relação com o TableController permanece em aberto — a decisão de herdar, compor ou manter completamente independente será tomada durante a implementação, conforme a necessidade real de reuso emergir.

---

OBJETIVO

• Criar uma camada dedicada para leitura de views do banco
• Expor cada view como um endpoint REST próprio, separado das rotas do Manager
• Integrar o registro de views ao processo de setup e atualização da model
• Organizar as views em uma pasta estrutural própria dentro do projeto

---

NECESSIDADES

• Criar a pasta views/ como módulo estrutural da controladora
• Cada view do banco deve ter sua representação como classe dentro de views/
• A model de atualização deve reconhecer as views e registrá-las no ambiente durante instalação e atualização
• O sistema de busca deve ser próprio — independente do SelectManager do TableController
• Endpoints dedicados por view, sem acoplamento às rotas do /{sufix}/Manager/{tabela}

---

ESTRUTURA PREVISTA

views/
├── __init__.py
├── [NomeDaView]         → Uma classe por view registrada no banco
└── ...

---

SISTEMA DE ROTAS

Cada view registrada ganha seu próprio endpoint REST, separado e dedicado. O padrão de rota ainda será definido, mas o comportamento esperado é:

Método	Rota	Descrição
GET	/{sufix}/View/{nome_da_view}	Listar registros da view com paginação e busca
GET	/{sufix}/View/{nome_da_view}/{recid}	Buscar registro específico da view

O sufixo seguirá o mesmo padrão configurável do sistema de rotas automáticas, mantendo consistência na API.

---

RESPOSTAS (modelo)

Código	Status	Descrição
200	OK	Consulta bem-sucedida
400	Bad Request	Parâmetros inválidos
404	Not Found	View ou registro não encontrado
500	Internal Server Error	Erro no servidor — verificar logs

---

INTEGRAÇÃO COM A MODEL

A refatoração da model de atualização contempla:

• Reconhecer a pasta views/ e suas classes registradas
• Verificar se as views existem no banco durante o processo de instalação
• Executar corretamente tanto em instalação quanto em atualização, sem conflito com tabelas

---

NOTAS TÉCNICAS

Nota	Detalhe
Somente leitura	O ViewController não expõe INSERT, UPDATE ou DELETE — views são estritamente consultáveis
Sistema de busca próprio	Não reutiliza o SelectManager — lógica de query construída dentro do próprio controller de view
Relação com TableController	Em aberto — herança, composição ou independência total serão decididas na implementação
Registro na model	As views devem ser declaradas para que a model saiba o que verificar no banco
Paginação	O endpoint de listagem deve suportar paginação desde o início

---

NOTA: Este é um sistema completamente novo. Nenhuma lógica existente deve ser reaproveitada sem validação — o risco de acoplar comportamento de escrita em um contexto de somente leitura é alto. A decisão de relação com o TableController deve ser documentada assim que definida.

[nicozsd]

Desenvolvido sistema de view e atualizado documentos readme junto com documentos issues, o mesmo já será disponibilizado na main para testar em repositório externos.