Orientação a Objetos e Banco de Dados

[MichelleAraujo 0]

Olá pessoal, tudo bem?

Gostaria de tirar uma dúvida com vocês que vem me "pertubando" a um tempo.

Quando trabalhamos com tabelas, a orientação de muitos especialistas é criar um classe para manipular os dados armazenados.
Minha dúvida é a seguinte: vamos dizer que tenho um banco de dados com mais de 20 tabelas. Dessas tabelas, algumas tem informações iguais entre si (o ID de uma outra tabela) e que em algumas tabelas somente vou fazer um select. Nesse caso, vou criar várias classes com apenas um método. Para cada classe, estou criando uma página que cria as interfaces. Por exemplo, se tenho a classe Carro.class.php eu vou ter uma página carros.php para chamar os métodos da classe Carro.

Minha dúvida é a seguinte: dessa forma é o ideal? Não ficaria um sistema com muitas classes? Poderia, por exemplo, dentro da classe Carro colocar métodos que fazem um select em outras tabelas que tem como coluna ID_Carro?

 

Vou esclarecer mais:
Tenho as seguintes tabelas:

*Carro, que tem as colunas ID_Carro, Nome, Quantidade.

*Roda, que tem as colunas ID_roda, ID_carro (em que carro ela está), Nome, Aro
*Volante, que tem as colunas ID_volante, ID_carro (em que carro ela está), Nome

Na primeira, eu vou fazer CRUD mas nas duas últimas só irei fazer um select. É indicado eu fazer uma classe Roda e Volante e suas respectivas páginas rodas.php e volantes.php?

Obrigada.

[William Bruno 1501]

1. Não é um problema "ter muitos objetos".

2. Orientação a objetos não é orientação a classes.

3. Existem patterns específicos para resolver esse tipo de problema. Não necessariamente você precisa de um objeto para cada tabela, não precisa ser esse ORM um para um. você pode ter um objeto que se divide em outras tabelas sim.

4. A view tanto faz.. ela é independente do objeto.

5. Pense em objetos e não em classes.

[Gabriel Heming 766]

Complementando o que já foi respondido, a orientação à objetos tem como intuito abstrair a solução de um problema (no seu caso o mapeamento relacional para o OO) para um contexto mais próximo do mundo real.

 

Existem muitos patterns para resolver esse seu problema, cada um com benefícios e malefícios. Normalmente se resumirão entre abstração X granularidade.

 

Por exemplo, o pattern DataMapper faz o serviço do mapeamento de forma excelente com uma alta abstração. Mas o seu efeito colateral é a alta granularidade de objetos/entidades envolvidas (Mapper <--> DomainObject) e os padrões que auxiliam no controle do data mapper (DomainFactory, IdentityMap, UnityOfWork, IdentityObject, DomainObjectAssembler, etc..). Com esse pattern, você pode separar perfeitamente as entidades de persistência das entidades utilizadas pelo seu software.

 

Por outro lado, existe, também os padrões TableDataGateway e RowDataGateway, que possuem uma granularidade menor que o DataMapper e, em consequência, uma abstração menor. Mas também é um ORM um para um.

 

Eu, particularmente, gosto do pattern DataMapper, inclusive dediquei um capítulo do tcc da minha pós para exemplificar o ganho na abstração relacional X OO.

 

Mudando um pouco o assunto, talvez a sua maior dificuldade não esteja na abstração em si, mas na arquitetura utilizada no seu projeto. Com os seus exemplos, não me parece utilizar uma arquitetura em camadas.