Lembro como se fosse ontem, em uma mensagem em private com um conhecido de lista de discussão, ele comentou que estava querendo abandonar DBware e utilizar componentes simples para apresentação de dados. Nem pensei duas vezes, e meu comentário na época ficou algo como “DBware é um framework maduro, implementado há bastante tempo, é como reinventar a roda”. Quem poderia imaginar que o destino me mostraria, na prática, que este colega tinha razão no que estava dizendo.

Meus problemas com DBware começaram quando eu percebi que estava fazendo a mesma coisa diversas vezes, e estava cometendo os mesmos erros nos mesmos lugares. Tudo isto apontava contra a orientação a objetos, uma abordagem que eu já conhecia e com a qual tinha até mesmo alguma experiência.

A abordagem anti-dbware que mais circula internet afora não era suficiente para remover o problema que eu tinha com meus componentes. Ajuda, pois eu poderia remover o problema do Edit/Post/Cancel/CheckBrowseMode imposto por decendentes de tdataset, mas ainda existe a necessidade de configurar cada componente, cada formulário alvo, todo um trabalho moroso e sujeito a erros.

O contato com objetos de negócio (BO), mapeamento objeto relacional (O-R mapping) e persistência de objetos (OPF), diga-se de passagem é assunto para outro post, removeu diversos problemas que eu tinha na construção das regras de negócio dos meus aplicativos, e por tabela fez com que eu enxergasse apresentação de dados de uma forma totalmente diferente.

Durante a busca de mais produtividade com a iteração com o usuário é que eu encontrei o padrão de projeto MVP. O uso desta técnica fez com que formulários complexos fossem configurados em segundos, e totalmente sem erros.

Para utilizar o padrão MVP é necessário utilizar objetos de negócio. No modelo de negócio, cada classe conhece quais outras classes que a compõe, por exemplo, uma classe TPedido sabe que seus objetos apontam para um objeto da classe TCliente, e também para um container com vários objetos da classe TPedidoItem.

Para configurar um formulário através do padrão MVP, tudo o que é necessário é dizer qual atributo do objeto de negócio deve ser ligado a qual componente visual do form. Por exemplo, o atributo Cliente do objeto TPedido será ligado ao componente TClienteComboBox do formulário. Com esta ligação, o framework que controla o sistema saberá o que colocar no combo, o que fazer quando o usuário abre este combo, o que fazer quando o usuário preenche um pedaço do nome do cliente e pressiona, por exemplo, o enter, e qual form deve ser aberto quando o usuário quiser incluir ou alterar os dados de um cliente. E o que foi feito para isto acontecer? Ligar TPedido.Cliente a TPedidoForm.ClienteComboBox, mais nada.

Mas como é possível tanta informação em uma única linha? A resposta é: reaproveitamento. No modelo de negócio, ao construir a classe TPedido você informa que ela tem um atributo Cliente, e que este atributo aponta para a classe TCliente. Com esta informação, o framework sabe que ele deve tratar a tabela que guarda os clientes quando o usuário fizer uma pesquisa no combo.

E o form, como é possível ele conhecer? Todos os forms são registrados no framework, informando que TClienteForm é usado para apresentar objetos TCliente. Então, quando o usuário está em um Combo que apresenta um TCliente, o framework sabe que precisa criar um TClienteForm caso precise apresentar ou alterar tal objeto.

Tudo isto é válido também para Edit, Grid, Bitmap, ou qualquer outro componente que apresente dados de objetos de negócio.