Orientação a Objetos e interação com o usuário - Delphi

A programação orientada a objetos não é uma "bala de prata", capaz de substituir a programação tradicional. Mas pode conviver, usando cada paradigma, naquilo que é melhor.

Qualquer usuário de Excel, sabe como é bom ter acesso a listas de informações e a capacidade de alterá-las, facilmente. Porém, é preciso ter em mente que isto geralmente é feito com bases de dados reduzidas.

Bancos de dados geralmente lidam com milhões ou bilhões de linhas e a ideia de carrega-las em um grid não faz muito sentido, não só pelo tempo e consumo de memória para receber dados de um servidor para exibi-lo ao usuário, mas principalmente pelo fato de que o usuário não está sozinho.

Bases de dados compartilhadas, utilizam locks para garantir as propriedades do banco de dados (ACID). Ao carregar dados para um usuário e deixar que ele manipule dados livremente, pode gerar conflitos com alterações realizadas por outros usuários, o que requer rotinas para resolução de conflitos, em que alguém perderá suas alterações.

Por isso, é muito importante que a arquitetura da aplicação seja bem pensada. Não sei se eu utilizaria uma classe para permitir alterações. Dá a impressão de que vamos fazer a alteração na camada da aplicação (leitura, alteração, escrita), que fere o conceito de transação no banco.

Uma classe somente de leitura, até poderia ser útil. Mas, ainda assim, geralmente as classes retornam todas as informações de uma entidade, sem necessidade, o que não é eficiente para o banco.

A programação até pode ser mais confortável para o desenvolvedor. Mas temos que lembrar que quem executa o procedimento é a aplicação e o banco. Logo deveria ser otimizada para a execução e não para a codificação.