" the dream of transparent O/R mapping is the same dream that fueled the development of fully transparent distributed objects in the early days of DSOM, CORBA and (D)COM "

http://friends.newtelligence.net/clemensv/PermaLink,guid,0fbf07a9-9e7a-4db4-a305-58250ac57a73.aspx

A minha parte favorita é:

"Many of the proponents of O/R mapping that I run into (and that is a generalization and I am not trying to offend anyone – just an observation) are folks who don't know SQL and RDBMS technology in any reasonable depth and/or often have no interest in doing so. It may be worth exploring how tooling can better help the SQL-challenged instead of obscuring all data access deep down in some framework and make all data look like a bunch of local objects"

Pessoalmente, o que sinto em relação a esta questão, e isto já há algum tempo, é que a utilização de uma camada de mapeamento O/R me tira um grau de controlo que estou habituado e que gosto de poder ter. Acabo por preferir uma abordagem com desenho e optimização "convencional" de modelos de dados, e geração de camadas de acesso a esses dados, para serem usados por outros componentes da aplicação. Assim sendo, não estou de acordo com a primeira frase da tua parte favorita das palavras do Vasters. Mas ele deve conhecer mais gente que eu :-).

Não tem totalmente a ver, mas li há dois dias um artigo  do .Net Developers Journal chamado "The OO Database Advantage", sobre bases de dados OO, que achei interessante e simples, dado que pouco sei sobre SGBS's não relacionais. Os exemplos são ilustrados com o db4o (http://www.db4objects.com/, open souce, versões para .Net e Mono), e parece-se muto com o resultados da utilização de O/R Mappers. O argumento do Vasters tb se aplicará a este tipo de sistemas?

O Vasters tem ainda um comentário relativamente ao facto de a ligação à BD ser uma fronteira explícita, e isto lembrou-me o facto de frequentemente se fazer "debug" nessa fronteira, usando ferramentas como o Profiler do Sql Server. Podemos estar a chegar à BD via código que não é nosso (e que se pode analisar usando coisas como o Reflector para .Net), mas a fronteira é um ponto privilegiado para ver o que se está a passar, e frequentemente muito eficaz.

Eu sou um grande adepto dos O/R, e seria estranho se não o fosse, como autor de uma "tentativa" de ferramenta de O/R.

No entanto, de vez em quando, e nalguns projectos, sinto que estou a matar uma mosca com um canhão. O investimento acaba por ter retorno,  não de forma imediata, mas quando se vai manter o projecto, e se precisa de fazer alterações à persistência física dos dados. Aí sim, o investimento acaba por valer a pena e revelar-se uma boa opção.

Como nunca tive em nenhum projecto que não tivesse que manter mais tarde, acabo sempre por ver o retorno.

Embora seja tudo menos frequente, também ja estive num projecto onde a meio do mesmo, se mudou de SGBD. Aí, o investimento foi definitivamente decisivo. Mas isto são situações raríssimas..

Mas.. já dei muitas vezes por mim a reinventar a roda, e a ter trabalho desnecessário com algo que seria imediato se tivesse a construir statements directos em cima do sgbd... 

Falta-nos um modelo por um lado mais declarativo, e por outro mais object oriented (cheira-me que os typed datasets, tentaram, frustradamente, encaixar nessa área), que atenue um pouco mais as fronteiras.

interessante post este sobre o/r mapping

http://friends.newtelligence.net/clemensv/PermaLink,guid,92eaea8c-778d-4512-af03-d332785f65f5.aspx

já agora deixo as minhas notas sobre este assunto.

recentemente desenvolvi 2 micro-projectos de aplicações winforms para meia duzia de utilizadores simultaneos com poucas regras de negocio, quase só recolher informação e despejá-la na base de dados.

como era aplicações que iam ser usadas num ambiente controlado optei por experimentar algumas coisas novas, nomeadamente o nHibernate. a decisão de optar por uma ferramenta deste género foi para eliminar ao maximo o tempo necessário a escrever código/sql para as operações CRUD. e devo dizer que, ultrapassado o tempo inicial de aprendizagem, que não é muito grande, de facto para este tipo de operações e mesmo para algumas pesquisas mais complexas fiquei convencido.

de um ponto puramente técnico é lindo ver coisas como querys polimorficos ou o lazy loading em acção :)
mas voltando ao pragmatismo é evidente que se nota um pouco de perda de performance (principalmente no primeiro pedido), se bem que tenha que dizer que também não perdi muito tempo a testar configurações alternativas ou a explorar o que podia fazer para melhorar a performance.

 

já agora queria saber a vossa opinião sobre este tipo de ferramentas e experiencias praticas que já tiveram com elas.

afinal não ficou por aqui:

http://friends.newtelligence.net/clemensv/PermaLink,guid,92eaea8c-778d-4512-af03-d332785f65f5.aspx

e continua noutro sitio...

http://udidahan.weblogs.us/archives/035838.html

 

João Pedro Martins
"é que a utilização de uma camada de mapeamento O/R me tira um grau de controlo que estou habituado e que gosto de poder ter"

eu acho que o o/r mapping cabe perfeitamente naquela ideia dos 80%/20%.
acho que é fantástico para 80% das situações mas se calhar vale a pena contornar nos outros 20%.
por exemplo cenários tipicos crud para persistir entidades simples acho que é a melhor solução, soluções de reporting aí prefiro continuar com as minhas storedprocs

"Acabo por preferir uma abordagem com desenho e optimização "convencional" de modelos de dados, e geração de camadas de acesso a esses dados, para serem usados por outros componentes da aplicação"

para mim acho que o o/r mapping é muito interessante porque me deixa pensar noutro tipo de problemas... se ainda tenho que pensar em como vou persistir ou recuperar os dados o meu mind-set deixa facilmente de ser oo para passar para data-oriented...
a persistencia de dados deveria ser basicamente uma especie de serviço... aliás mais interessante, digo eu, podia funcionar tipo garbage collection... quando um objecto não é mais necessario podia ser persistido ou algo parecido... claro que é uma visão simplista.

de qualquer forma estou a acompanhar (ainda só em leitura) o Linq e DLinq e parece-me que pode ser uma boa solução para estas duvidas existenciais.

 

A mim também me parece que um mapeamento o/r pode poupar muito trabalho, mas acho fundamental poder, nos casos em que é preciso, chamar directamente código que está a correr na Base de Dados.

E digo código e não stored proc. intencionalmente. Em vez de olhar para a integração o/r como algo que me faz esquecer da base de dados, preferia poder olhar para ela como uma plataforma que me permita ora persistir objectos ora invocar serviços que estejam a "correr" do outro lado, como valor e não como um incómodo.

Até posso não pensar muito se do outro lado está uma BD relacional, mas tenho de ter consciência de que estou a fazer uma chamada para fora das fronteiras do meu processo/serviço. Eu tenho de saber que puxar 10000 objectos para o "meu lado" é em princípio incomportável e que, portanto, não posso alegremente só pensar no Object Model que tenho em memória e que alguém se preocupe com o "detalhe" da persistência.

O Don Box dizia qq coisa de parecido quando dizia que isto dos Object Broker tornarem transparente a localização dos objectos não fazia muito sentido. Quem acede a algo remoto deve saber que o está a fazer.

Também estou expectante em relação ao DLinq (o termo mais correcto seria babado :) )

Este artigo vale a pena e enumera soluções muito interessantes para o nosso problema:

http://devhawk.net/2006/03/28/The+Dual+Schema+Problem.aspx

Acho que levantas um aspecto muito interessante...de facto, aceder à BD é sair da nossa fronteira aplicacional, pelo que tornar essa saída transparente é muito semelhante a tornar transparentes acessos a objectos remotos. Há riscos, como o de se ignorarem latências, e as características específicas de algo como uma base de dados (como sejam a transaccionalidade - que atravessa a fronteira, e o seu próprio fim, ser um repositório de grandes volumes de dados, que até tem patterns próprios -- uma BD é um serviço de dados?). Acho que é muito fácil ir pelo caminho do "vamos tornar isto transparente".

Já dei este link mais de uma vez, mas o artigo vale realmente a pena, apesar da venerável idade: A Note on Distributed Computing, Samuel C. Kendall, Jim Waldo, Ann Wollrath and Geoff Wyant, 1994

 

 

Esta tema é sempre interessante... antes de mais deixem-me dizer que concordo em parte com o que foi dito, no entanto este tema leva-nos a velha discussão "...regras de negócios na BD / independência da BD... etc". Já estive em projectos relativamente grandes em que optei por diferentes abordagens, um dos pontos que sobressai é “performance” . Aqui,  em alguns casos, sou defensor de colocar lógica de negócio na BD (User Functions, triggers e por vezes SP).

 

Este dava uma boa sessão de GASP :)

Rocha:

 

Este dava uma boa sessão de GASP :)

Sem dúvida.

O problema típico que traz este tipo de discussões tem a ver com a tentativa de utilizar as mesmas ferramentas para resolver questões completamente distintas.
Separando os projectos em duas grandes áreas:
 1) Backoffices/Frontoffices de administração
 2) Frontends e acesso a grandes volumes de dados com grandes requisitos de performance.
Temos:
- No caso 1 temos, típicamente, operações complexas em volumes de dados relativamente reduzidos e o objectivo é implementar aplicações grandes com inúmeras areas de gestão de detalhe que têm que ter desenvolvimentos de funcionalidades à medida, a utilização de O/R trás ganhos de produtividade e de manutenção de código indiscutíveis.
- No caso 2 temos questões de optimização de performance em que é essencial ter um controlo mais fino e o mais directo possível à fonte de dados. Para este tipo de situações, nomeadamente as de alta performance, é tipicamente dispensavel e, salvo excepções desrecomendada a utilização de camadas intermédias de O/R, pois trazem peso adicional que obrigam na maior parte dos casos a encontrar soluções para contornar os problemas trazidos.

Claro que existem soluções intermédias e ferramentas que trazem o melhor dos dois mundos ;-)

Abraços!

PS: sei que a discussão já tinha arrefecido ha um mês, mas acho que este é um tema sempre actual...

Já usei ferramentas o/r para um projecto de grande dimensão, e apesar de indiscutivelmente trazerem ganhos de produtividade, apresentaram quando a mim, algumas limitações que devem ser consideradas:
- A forma como eram geridas as transacções
- Questões relacionadas com performance
- A falta de controlo no código gerado

Admito que estas questões dependam da ferramenta escolhida, mas o que acabamos por fazer foi gerar toda a camada de acesso a dados utilizando o CodeSmith, que não sendo uma ferramenta o\r permitiu a criação dessa camada com base em templates, desta forma temos ganhos de produtividade grandes, mas também um maior controlo do código gerado.
Mas também acho, que o sucesso deste e doutro tipo de ferramentas, depende em muito da preparação e capacidade da equipa de projecto em perceber as suas vantagem, o modelo subjacente ás mesmas, e como as usar de forma correcta.

Ok... sei que já venho um pouco tarde :) Mas vou dar a minha opinião acerca deste assunto.

Eu não uso O/R mapping...

Uso sim uma framework base que usando ferramentas de automatização me gera todas as SP's para CRUD e uma classe base para aceder a esses SP's que depois por sua vez é usada por uma BRL (business rules layer) que se encarrega de tratar das validações e da gestão de transacções e afins. A BRL de cada módulo é também gerada automaticamente (o codigo) sendo que depois é extendida e mantida conforme as necessidades.

Pessoalmente optei por esta via para:
- Ter total flexibilidade na implementação quer da BRL quer da DAL sem ter de estar limitado em funcionalidade, onde foram implementados varios membros overridable para se poder alterar o comportamento
- Ter performance... todas as tabelas são acedidas por SP's a 100%, até em operações como paginação de dados e afins, e a forma de fazer as chamadas é o mais directo possível


Obviamente que em termos de manutenção ter um O/R mapper pode ser vantajoso mas a realidade é que na prática as vantagens de flexibilidade e performance podem fazer mais sentido.

Cada caso é um caso obviamente.

Não acho que seja minimamente interessante pensar em O/R como uma ferramenta de abstracção para programadores que não sabem nem querem saber o que está por baixo. Pelo menos no meu contexto. Embora considere que em alguns casos isso até possa fazer sentido, no meu caso, que é de um ISV de pequenas dimensões, não posso de forma alguma aceitar que um programador cá não conheça bem o modelo de dados e não saiba como o mesmo está implementado.

Alias um programador aqui tem até de perceber pelo menos as bases da área de negócio para onde está a desenvolver.

Em termos de manutenção da minha experiência pessoal os ganhos que O/R traria em relação ao sistema que usamos actualmente (DAL + BRL + Geracção de Codigo automatico) não justifica a mudança, pelo menos para já.

Just my 2 cents