>>>>> "LD" == Leandro DUTRA, Guimarães Faria Corcete writes:
GF> Até aí morreu o Neves. Novamente, qual o problema de transformar os
GF> dados fora da base? Isso nada tem a ver com as regras organizacionais
GF> (‘de negócio’), ou com o mapeamento OR.
>>
>> Discordo, tem tudo a ver, porque quando se desenvolve orientado a
>> objetos você precisa de um ponto de entrada dos dados no seu modelo OO
LD> E o que isso tem a ver com essa transformação? Ou boiei…
O que tem a ver é que mapeadores facilitam a integração com pontos de
entrada de dados em bibliotecas OO externas ao banco de dados que
realizam as transformações, evitando assim que essa integração precise
ser reimplementada por inteiro para cada projeto. O meu argumento é de
que esse tipo de integração é uma aplicação perfeitamente válida de
mapeadores, até dos mais ruins. A alegação anterior era:
EC> parte dos casos, não existe saída fácil. Mas existe um problema
EC> recorrente em desenvolvimento que é inflar os dados normalizados do
EC> banco pruma estrutura de dados sã que o teu software pode consumir, e
GF> Mas aí é um problema ou de um modelo ruim (inconsistente), ou
GF> incompleto (faltam as visões [VIEW]s que dêem os resumos que o
GF> programa precisa) ou de um programa ruim. Ou de qualquer combinação
GF> dessas três.
E isso nem sempre é verdade, muitas vezes os dados precisam de
transformações complementares aos resumos das views, isso não implica
em um "programa ruim" ou modelo incompleto, e é um caso onde é
razoável utilizar mapeadores como mecanismo de integração.
LD> Nem um pouco difícil. Bastante simples, até: em SQL, especificamos o
LD> que queremos, e podemos criar tipos abstratos de dados, isolando
LD> aplicações de muitas mudanças nos tipos e nas estruturas base, físicas
e
LD> até, nalguma medida, lógicas; enquanto em OO temos de dizer como fazer,
LD> o que acaba por nos dar o problema das classes base mutantes…
Poderia se argumentar que existem implementações de OO que também
possuem essas propriedades, caso fosse o tópico. Porém, seria
irrelevante numa discussão objetiva, pois objetividade requer métrica.
--
Eden Cardim
+55 11 9644 8225
e...@insoli.de
http://insoli.de
_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
