>>>>> "GF" == Guimarães Faria Corcete DUTRA, Leandro writes:
GF> Mas essa transformação não tem nada a ver com ORM! Não tem se você não quiser enxergar dessa forma. Mas é perfeitamente razoável usar um ORM como um transformador resultset -> JSON (ou XML, ou CSV, ou tabulado, ou SVG, etc.), usando as abstrações típicas de um ORM (sic) onde você entrega os dados do resultset pruma classe e ela cuida de serializar no formato que você quiser. O ORM (sic) diz qual(is) classe(s) é(são) responsável(is) por serializar esse conjunto de dados. Qual o problema dessa abordagem em particular? Eu vejo um problema quando os desenvolvedores tentam abstrair as tabelas em classes equivalentes, etc. Isso realmente dá vazão aos desenvolvedores modelarem o código de maneira errada. Mas quando você tem um mecanismo que abstrai as responsabilidades de transformação de dados vindos do banco, não há o menor problema, até porque você precisa fazer isso de um jeito ou de outro. Essa mesma abordagem pode ser feita sem orientação a objetos, em linguagens funcionais, por exemplo, você delegaria a responsabilidade pruma função. GF> Json não é particularmente orientado a objetos! Engano seu e isso é off-topic, mas JSON é sigla de JavaScript *Object* Notation. Uma estrutura JSON mapeia diretamente prum protótipo de objeto em javascript que pode despachar métodos polimórficos, etc. etc. Eden Cardim +55 11 9644 8225 e...@insoli.de -- [Insolide Soluções de TI Ltda.]: http://insoli.de
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
