Mapeamento objeto/relacional

Oi pessoal,
eu li a seguinte frase não lembro em qual site: “mapear objetos para tabelas de um banco de dados relacional pode destruir o encapsulamento”.
Então eu gostaria de um exemplo de uma tabela representando um objeto onde os dados privados fiquem sujeitos a alterações de forma incorreta.
Pois eu tenho uma agenda onde gurado meus contatos, usei o JDBC e não tive maiores dificuldades.
Eu só tenho acesso aos dados pela aplicação não posso ir direto no banco e alterá-los, como eu posso então destruir o encapsulamento?
E já que eu falei em JDBC, pq não é legal escrever instruções SQL no código da minha aplicação Java?

[quote=“geofrey”]
E já que eu falei em JDBC, pq não é legal escrever instruções SQL no código da minha aplicação Java?[/quote]

:arrow: Caso você tenha que alterar o banco de dados, pode ser um problema ter SQL dentro do código
:arrow: Em uma alteração de SQL você precisa recompilar todos o código (pior ainda se essa alteração você tiver que fazer diretamente no seu cliente)
:arrow: Acompanhando a o ponto de cima, manutenção e visualização do código fica mais simples

Eu estou tentando brincar com Hibernate (para Mapeamento O/R) e quando for usar o HQL tirar ele do código usando arquivos de properties, vamos ver o que vai acontecer no futuro :wink:

Eis um artigo interessante:
http://www.cin.ufpe.br/~phmb/papers/javabdr.ps

A Paz!!

Bom,

Se apenas uma aplicação em todo o mundo [e, talvez, um ocasinal DBchato para fazer uns índices e tunning em geral] acessar sua base, primeiro de tudo parabéns [isso não é tão comum em alguns lugares :(], agora vamos lá.

Para preservar o encapsulamento, todo mundo [clientes, serviços diversos, etc.] devem consultar os dados persistidos [que, por um acaso, estão em BD, mas poderiam estar em arquivos textos, prevalência, pqppência…] através desta camada. Assim você garante que está falando em Objectos, e que nenhum engraçadinho vai quebrar alguma restrição [invariância] dos seus objetos persistidos. O grande problema é que o susbsitema de persistêrncia [BD] não pode ser acessível por muita gente.

Bom, SQL não é Orientado a Objectos. Com SQL você pode destruir qualquer invariante, criando triângulos de quatro vértices, vacas de duas cabeças e açucar salgado. Quando usando SQL, você está na mão de quem o implementar. Aí alguém diz: ‘mas se eu não confiasse nos meus programadores, para que os contrataria?’ minha resposta é: Então, pare de usar membros privados nas suas classes. Para que? Você não confia nos seus programadores?

Infezlimente tenho que sair, se render, continuamos :wink:

[]s

Valeu a ajuda pessoal.
E já que estamos falando de mapeamento, como o prevayler não usa tabelas, ele não precisa mapear nada correto?
Existe alguma outra ferramenta que tenha essa característica?

[quote=“paulohbmetal”]Eis um artigo interessante:
http://www.cin.ufpe.br/~phmb/papers/javabdr.ps
[/quote]

Esse link não abriu aqui… :cry:

Vc pode deixar os HQL no mesmo arquivo que vc faz o mapeamento. É bem mais prático.

[]'s

Vc pode deixar os HQL no mesmo arquivo que vc faz o mapeamento. É bem mais prático.

[]'s[/quote]

Referências?? Referências?? Referências?? Referências?? :lol: :lol: :lol:

Eu não vi falando isso no site do Hibernate, eu vi em exemplo que achei por aí e não vou conseguir achar de novo agora. Mas funciona mais ou menos assim:

<hibernate-mapping>
	<class name="Email" table="Emails">
		<id name="id" type="java.lang.Long" unsaved-value="null">
			<generator class="identity" />
		</id>
		<property name="endereco"/>
	</class>

	<query name="unassignedEmail">
		<![CDATA[
			from Email email
			where endereco = :endereco
		]]>
	</query>
</hibernate-mapping>

Pra usar a query:

Query query = HibernateSessionFactory.getSession().getNamedQuery("unassignedEmail");
query.setString("endereco", "foo@bar.com");
List list = query.list();

[]'s

[quote=“geofrey”]
E já que estamos falando de mapeamento, como o prevayler não usa tabelas, ele não precisa mapear nada correto?
Existe alguma outra ferramenta que tenha essa característica?[/quote]

Exato. Mapeamento é uma gambiarra para transformar uma coisa em outra, um objeto em tabelas [você pode chamar de ‘adaptador’ ou qualquer outro termo chique, mas não deixa de ser uma gambiarra!!]. Uma persistência prevalente ou qualquer outra que lide com objetos não precisa de um mapeamento tão extenso. No máximo, você pode precisar converter tipos de dados [como a IDL CORBA] se sua persistência for em outra tecnologia [no caso do Prevayler, é Java com Java, sem rpoblemas :wink: ].

[]s

Cara estranho pois aqui abre. :roll: Cara eu achei no google:
http://www.google.com.br/search?q=javabdr.ps&ie=UTF-8&hl=pt-BR&meta=
Apesar de ser o mesmo link. Tenta lá…

A Paz!!

[quote=“geofrey”][quote=“paulohbmetal”]Eis um artigo interessante:
http://www.cin.ufpe.br/~phmb/papers/javabdr.ps
[/quote]

Esse link não abriu aqui… :cry:[/quote]

Valeu pelas explicações amigos.
O link funcionou no meu estágio, aqui em cas foi q deu algum problema no dia…
agora sou eu quem indico um link:
http://www.intersystems.com.br/cgi-bin/nph-mgwcgi?MGWLPN=ISC&wlapp=ISC&guid=1T97X0twVJRUj0Ywxmp8QmagNqlRTS

fala sobre o caché, vocês que são mais esclarecidos a respeito desse tema de mapeamento vejam se essa idéia vale mesmo a pena dá até pra baixar o demo.
:wink: