O grande engano e o MVC - Parte 2

Estava fazendo um projeto com o nome de PureMVC para colocar em prática algumas ideias do post anterior, até que resolvi procurar na google se já existira algo com esse nome e encontrei, o que me deixou feliz, pelo menos não sou a única pessoa a pensar assim, o pureMVC é um framework com suporte a diversas linguagens de desenvolvimento, não posso falar mais do que isso pois ainda não estudei ele.

Mas o que me chamou a atenção foi o diagrama conceitual do rapaz framework onde no centro existe o MVC e nas extremidades a Interface do Usuário (UI) e o banco de dados (DB).

 

Sem mais para o momento, a dica fica registrada (UI - MVC - DB).

Componente de Acesso Dados

O componente de acesso dados já disponibiliza recurso para gravação de objetos. E atualmente está em teste a versão com os métodos carregar objetos e listar objetos.
No entanto o método para carregar objetos só carrega propriedades de tipo primitivo do C# (int, string, ...) e para a orientação a objeto isso é uma barreira.
As classes se relacionam e portanto instanciamos objetos dentro de outros objetos. O grande desafio está em controlar essa recursividade nos relacionamentos.
Um forma de controle seria carregar os objetos sob demanda. No entanto isso gera outro problema de performance com o banco de dados qdo precisamos carregar uma lista de objetos.
Por exemplo: Preciso de uma listagem de produtos que me retorne idf, nome e descrição de categoria. O idf e o nome são atributos de tipo primitivo, int e string respectivamente, no entanto a descrição de categoria está em outro objeto, portanto cada produto da listagem vai fazer uma chamada de banco para carregar a sua categoria.
Quem sabe tratar a recursividade em apenas dois niveis seja uma idéia interessante mas também não atende a todos os casos.
Acho que esse assunto pode render e o componente de acesso dados pode reduzir ainda mais os custos de implementação dos objetos.

teste

teste writter

O grande engano e o MVC

O titulo parece estranho e o que eu realmente quero dizer não é que o modelo MVC está incorreto ou está correto.

O que tenho em mente é que, em meados de não sei quando, houve um pequeno engano na sua interpretação e utilização, o desenvolvimento em 3 camadas teoricamente deve facilitar o desenvolvimento e a manutenção de um sistema, mas os formulários estão totalmente dependentes das classe de controle ou modelo.

Heim ?

Nos modelos criados por mim e pela maioria dos programadores os webforms são conceitualmente a view do MVC, ou seja, se eu quiser transformar o sistema de desktop para web vou ter uma grande dor de cabeça, justamente por causa dessa depedencia e chamada diretas as classes internas além dos diversos códigos que estão no code-behind.

Uma solunão seria modelar a view como classes assim como as controladores ou modelos, e apenas criar um link do formulário web ou windows form com a classe de view, sem dependência webform seria o que ele realmente deveria ser, burro!

Como? não sei … mas é algo para se pensar

Análise Orientada a Objetos

As instituições de ensino atualmente tem como padrão em cursos voltados a área de desenvolvimento de sistemas a matéria “Programação Orientada a Objetos”, onde os conceitos básicos da OO são difundidos. Quando o nome é alterado para qualquer outro mais forte ou mais elegante, a matéria continua focando no desenvolvimento “codificação”.

Mas o que eu realmente sinto falta, é uma matéria de Analise Orientada a Objetos (AOO), ela não existe, as instituições simplesmente esquecem que a programação não é nada sem análise.

O resultado é que um monte de sistema que teoriamente são orientados a objetos mas não passam de classes de conexão com a base de dados.

É uma vergonha !!!