Questão de Banco de Dados — Arquitetura ANSI/SPARC — INSTITUTO AOCP 2024

Camada de persistência: separação de responsabilidades e boas práticas

Gabarito: letra C. A separação clara entre a camada de persistência e a lógica de negócios é uma boa prática fundamental de arquitetura de software, pois promove a coesão, reduz o acoplamento e facilita a manutenção e evolução do sistema. Essa é a alternativa que reflete corretamente os princípios de design de sistemas, enquanto as demais apresentam afirmações incorretas ou exageradas sobre o papel da camada de persistência.

A camada de persistência é o componente de um sistema responsável por intermediar a comunicação entre a lógica de negócios (as regras que definem o comportamento da aplicação) e o mecanismo de armazenamento de dados, que geralmente é um Sistema Gerenciador de Banco de Dados (SGBD). Seu papel é isolar a aplicação dos detalhes de como os dados são armazenados, recuperados e manipulados, oferecendo uma interface de alto nível para as operações de leitura e escrita. Essa abstração é o que permite que o banco de dados seja alterado (por exemplo, migrar de um SGBD para outro) sem que a lógica de negócios precise ser reescrita.

O princípio que fundamenta essa separação é o da independência de dados, um conceito central na arquitetura de bancos de dados. A arquitetura ANSI/SPARC, também conhecida como arquitetura de três esquemas, foi proposta justamente para separar as aplicações do usuário do banco de dados físico. Ela divide o sistema em três níveis: o nível externo (visões dos usuários), o nível conceitual (estrutura lógica de todo o banco) e o nível interno (armazenamento físico). Os mapeamentos entre esses níveis garantem que alterações em um nível não afetem os demais, proporcionando a independência lógica e física dos dados.

Na prática, essa separação se manifesta em padrões de arquitetura como o MVC (Model-View-Controller), em que o Model é responsável pela persistência e pela lógica de negócios, e em padrões de acesso a dados como o DAO (Data Access Object) e o Repository. A ideia central é que a camada de persistência deve ser desacoplada da interface do usuário e da lógica de negócios, comunicando-se com elas por meio de interfaces bem definidas. Isso permite que cada camada evolua de forma independente, que os testes sejam mais fáceis de realizar e que o sistema como um todo seja mais robusto e flexível.

A banca explora aqui um tema de arquitetura de software, testando se o candidato compreende o papel e os limites da camada de persistência. As alternativas incorretas apresentam visões distorcidas ou exageradas, como a ideia de que a persistência deve ser acoplada à interface do usuário, que um ORM elimina a necessidade de SQL, ou que a camada de persistência é responsável apenas pela escrita de dados. A alternativa correta, por sua vez, afirma um princípio de design amplamente aceito e que está alinhado com as boas práticas de desenvolvimento de software.

Alternativa A — ❌ Incorreta

A camada de persistência não deve ser acoplada diretamente à interface do usuário. Pelo contrário, o acoplamento entre essas camadas é uma má prática de arquitetura, pois torna o sistema rígido e difícil de manter. A interface do usuário deve se comunicar com a lógica de negócios, que por sua vez utiliza a camada de persistência. O acoplamento direto entre a interface e a persistência viola o princípio da separação de responsabilidades e dificulta a evolução independente de cada parte do sistema.

Alternativa B — ❌ Incorreta

Um mapeamento objeto-relacional (ORM) não elimina a necessidade de SQL e não melhora o desempenho de todas as consultas. Um ORM é uma ferramenta que facilita a conversão entre o modelo de objetos da aplicação e o modelo relacional do banco de dados, mas ele ainda utiliza SQL (ou uma linguagem de consulta similar) por baixo dos panos. Além disso, o ORM pode até piorar o desempenho de consultas complexas, pois a geração automática de SQL nem sempre é otimizada. O desempenho depende de diversos fatores, como a modelagem do banco, os índices e a forma como as consultas são escritas.

Alternativa C — ✅ Correta ⟵ GABARITO

A separação clara entre a camada de persistência e a lógica de negócios é uma boa prática de arquitetura de software. Essa separação promove a coesão (cada camada tem uma responsabilidade bem definida) e facilita a manutenção do sistema, pois alterações em uma camada não impactam diretamente a outra. Essa é a alternativa que está alinhada com os princípios de design de sistemas e com a arquitetura em camadas.

Alternativa D — ❌ Incorreta

A camada de persistência é responsável tanto pela escrita quanto pela recuperação de dados. Ela abstrai todas as operações de acesso ao banco de dados, incluindo consultas (SELECT), inserções (INSERT), atualizações (UPDATE) e exclusões (DELETE). A ideia de que a recuperação de dados deve ser feita por uma camada separada é incorreta e não corresponde ao papel da camada de persistência.

Alternativa E — ❌ Incorreta

A utilização de procedimentos armazenados na camada de persistência nem sempre simplifica a lógica de negócios e nem sempre melhora a escalabilidade do sistema. Procedimentos armazenados podem ser úteis em alguns cenários, mas também podem tornar o sistema mais complexo e difícil de manter, além de criar um acoplamento forte com o banco de dados. A escalabilidade depende de diversos fatores, e o uso de procedimentos armazenados não é uma garantia de melhoria.

Gabarito: letra C