BISDAO - Histórico de revisão

Rodrigogml em 01h26min de 20 de maio de 2019

2019-05-20T01:26:18Z

← Edição anterior		Edição das 01h26min de 20 de maio de 2019
Linha 1:		Linha 1:
	A persistência do BIS é automatizada como um sistema de ORM ~~automático~~, ~~mas~~ melhor ~~definido para as necessidades de Patterns~~ do BIS~~. Gerando menos problemas~~ de ~~persistência, mais autonomia no desenvolvimento~~ e ~~praticidade na maior parte das tarefas que envolvem o banco~~ de ~~dados~~.		A persistência do BIS é automatizada como um sistema de ORM próprio chamado de BISDAO. Embora não seja tão maleável quanto os sistemas já consolidados no mercado, tem ótima performance, é melhor adaptado ao Framework do BIS e por não fazer injeção de código permite que VOs e métodos de persistência customizados sejam alterados por hot-deploy.

	O principal objetivo do BISDAO é receber objetos e persisti-lo (inserindo/atualizando), exclui-lo ou encontrar os objetos no banco de dados automaticamente. Abstraindo a questão objeto x relacional do banco de dados, e diminuindo (ou eliminando na maioria dos casos) a necessidade de implementação códigos SQL pelo desenvolvedor.

	~~== Regras~~ do ~~Funcionamento ==~~		O principal objetivo do BISDAO é receber os VOs e persisti-lo (inserindo/atualizando), exclui-lo ou encontra-los no banco de dados automaticamente. Abstraindo a questão objeto x relacional do banco de dados, e diminuindo (ou eliminando na grande maioria dos casos) a necessidade de implementação códigos SQL pelo desenvolvedor.

	# Embora utilize os conceitos do banco de dados (por óbvio já que utiliza um banco dados), não segue os padrões definidos no JPA. Assim, nenhuma annotation do JPA é utilizada nas entidades do BIS.

	~~# O BISDAO manipula os objetos/entidades padrão~~ do ~~BIS automaticamente, isto é, para ser persistido '''é necessário que a entidade seja descendente do [[BISVO]]'''.~~		= Regras do Funcionamento =

	== Estrutura do Banco de Dados ==
			# Embora utilize os conceitos do banco de dados, não segue os padrões definidos no JPA. Assim, nenhuma annotation do JPA é utilizada nos VOs do BIS.

			# O BISDAO manipula os VOs automaticamente. E não aceita nenhum outro tipo de objeto, isto é, para ser persistido '''é obrigatório que a entidade seja descendente do [[BISVO]]'''.

			= Estrutura do Banco de Dados =

	O BIS é uma plataforma que suporta múltiplas empresas sendo manipuladas pela mesmas instância. Assim um mesmo servidor e mesmo banco de dados será utilizado para gerenciar várias empresas. Para isso o sistema utilizará vários "schemas" (ou catálogos) do banco de dados, sendo:		O BIS é uma plataforma que suporta múltiplas empresas sendo manipuladas pela mesmas instância. Assim um mesmo servidor e mesmo banco de dados será utilizado para gerenciar várias empresas. Para isso o sistema utilizará vários "schemas" (ou catálogos) do banco de dados, sendo:
Linha 15:		Linha 18:
	* '''bis_<empresa>''' - com este nome deve existir um schema para cada empresa que o sistema gerencia. Isto é, para cada empresa que o BIS atender, um novo schema é criado para armazenar os dados específicos da empresa, como itens/produtos sendo vendidos, documentos fiscais, etc.		* '''bis_<empresa>''' - com este nome deve existir um schema para cada empresa que o sistema gerencia. Isto é, para cada empresa que o BIS atender, um novo schema é criado para armazenar os dados específicos da empresa, como itens/produtos sendo vendidos, documentos fiscais, etc.

	=== Configuração das FK ===		== Configuração das FK ==


	Ao criar a associação entre as tabelas do banco de dados devemos seguir as seguintes regras para o bom funcionamento do BISDAO:		Ao criar a associação entre as tabelas do banco de dados devemos seguir as seguintes regras para o bom funcionamento do BISDAO:
Linha 36:		Linha 40:
	{{nota\|Relacionamentos N:N UniqueIndex\|Normalmente em relacionamentos N:N as colunas do relacionamento são a própria PrimaryKey da tabela, o que já evita a inserção de múltiplas entradas. É importante que sejam definidas como PrimaryKey ou coloque uma constante de UniqueIndex para que em caso de inserção de duplicada dos registros de associação termine em erro. Permitindo que o desenvolvedor detecte e corrija.}}		{{nota\|Relacionamentos N:N UniqueIndex\|Normalmente em relacionamentos N:N as colunas do relacionamento são a própria PrimaryKey da tabela, o que já evita a inserção de múltiplas entradas. É importante que sejam definidas como PrimaryKey ou coloque uma constante de UniqueIndex para que em caso de inserção de duplicada dos registros de associação termine em erro. Permitindo que o desenvolvedor detecte e corrija.}}


			{{nota\|Objeto Em Uso e Não pode ser Excluído\|Quando o BIS recebe o erro de que "falha de constraint" do banco de dados, ele assume que não pode ser excluído porque o objeto está em uso por algum outro objeto e retorna uma exception específica para este tipo de erro.

			É ma exception do tipo Critica com o código de erro "ERR100067". Essa exception deve ser tratada quando se espera que esse tipo de coisa possa acontecer, como por exemplo, um objeto que pode ser excluído desde que ainda não esteja em uso. Apesar de ter uma mensagem padrão no Bundle para este código, é recomendável criar uma mensagem para cada caso específico.}}


	== Relacionamento Entre Objetos ==		= Relacionamento Entre Objetos =

	Os relacionamentos entre objetos serão declarados de acordo com o "tipo do relacionamento" constituído entre eles para que o BISDAO saiba como proceder quando for atualizar, inserir ou excluir os objetos. Entender o relacionamento entre os dois define a boa arquitetura ao criar os objetos:		Os relacionamentos entre objetos serão declarados de acordo com o "tipo do relacionamento" constituído entre eles para que o BISDAO saiba como proceder quando for atualizar, inserir ou excluir os objetos. Entender o relacionamento entre os dois define a boa arquitetura ao criar os objetos:

	=== Associação ===		== Associação ==

	O tipo de relacionamento '''Associação''' é utilizando quando ambos os objetos existem separadamente, mesmo que não tenham vínculos. Por exemplo:		O tipo de relacionamento '''Associação''' é utilizando quando ambos os objetos existem separadamente, mesmo que não tenham vínculos. Por exemplo:
Linha 52:		Linha 60:
	* '''Alteração''' - Em caso de alteração o objeto será comparado com o atual no banco de dados. Objetos que não estejam mais presentes no objeto sendo persistido, terão sua associação removida, novos objetos terão associação criada. A contra-parte nunca será excluída, e nem criada.		* '''Alteração''' - Em caso de alteração o objeto será comparado com o atual no banco de dados. Objetos que não estejam mais presentes no objeto sendo persistido, terão sua associação removida, novos objetos terão associação criada. A contra-parte nunca será excluída, e nem criada.

	=== Composição ===		== Composição ==

	O relacionamento do tipo composição indica que o objeto associação é uma "extensão" deste objeto. Ou seja, ele faz parte do objeto principal, e como tal será manipulando junto com o objeto pai. Por exemplo:		O relacionamento do tipo composição indica que o objeto associação é uma "extensão" deste objeto. Ou seja, ele faz parte do objeto principal, e como tal será manipulando junto com o objeto pai. Por exemplo:
Linha 64:		Linha 72:


	=== Annotation @BISDAO ===		== Annotation @BISDAO ==

	Toda entidade deve ter a Class Annotation ''@BISDAO'' para configurar a tabela a qual o objeto se refere.		Toda entidade deve ter a Class Annotation ''@BISDAO'' para configurar a tabela a qual o objeto se refere.
Linha 79:		Linha 87:
	* '''table''' - Indica o nome da tabela onde o conteúdo deste objeto é guardado.		* '''table''' - Indica o nome da tabela onde o conteúdo deste objeto é guardado.

	=== Relacionamento Atributo do Objeto x Coluna do BD ===		== Relacionamento Atributo do Objeto x Coluna do BD ==

	Para que um atributo do objeto seja relacionado corretamente com uma coluna da tabela (especificada na Annotation @BISDAO) é necessário que o atributo tenha uma @[[BISMeta Annotations]]. Nela constarão várias informações sobre o atributo, incluindo a coluna. '''Caso o nome da coluna não seja especificado, o BISDAO assume que o nome da coluna é exatamente o mesmo nome do atributo''', ou seja, caso o mesmo nome seja utilizado na coluna do banco quando no atributo do objeto, não é necessário especificar o atributo coluna na Annotation. Isso deixa o código menos poluído.		Para que um atributo do objeto seja relacionado corretamente com uma coluna da tabela (especificada na Annotation @BISDAO) é necessário que o atributo tenha uma @[[BISMeta Annotations]]. Nela constarão várias informações sobre o atributo, incluindo a coluna. '''Caso o nome da coluna não seja especificado, o BISDAO assume que o nome da coluna é exatamente o mesmo nome do atributo''', ou seja, caso o mesmo nome seja utilizado na coluna do banco quando no atributo do objeto, não é necessário especificar o atributo coluna na Annotation. Isso deixa o código menos poluído.


	== Mapeamento do Relacionamento ==		= Mapeamento do Relacionamento =

	O mapeamento de todos os relacionamentos são feitos através da @BISMetaRelationshipField.		O mapeamento de todos os relacionamentos são feitos através da @BISMetaRelationshipField.

	=== Associação 1:1 ===		== Associação 1:1 ==

	=== Associação 1:N ===		== Associação 1:N ==


Linha 111:		Linha 119:
	* '''targetRelationship''' - Classe do objeto utilizado na contra-parte. Normalmente a mesma classe passada no "generics" da coleção. '''Quando não é uma coleção de objeto, este atributo pode ser omitido e será usado o próprio tipo do Field declarado na classe'''. Neste caso o BISCompanyVO.		* '''targetRelationship''' - Classe do objeto utilizado na contra-parte. Normalmente a mesma classe passada no "generics" da coleção. '''Quando não é uma coleção de objeto, este atributo pode ser omitido e será usado o próprio tipo do Field declarado na classe'''. Neste caso o BISCompanyVO.

	=== Associação N:N ===		== Associação N:N ==

	[[File:AssociacaoNN.png\|center\|frame\|Associação ManyToMany entre BISCompanyVO e BISUserVO]]		[[File:AssociacaoNN.png\|center\|frame\|Associação ManyToMany entre BISCompanyVO e BISUserVO]]
Linha 144:		Linha 152:
	Além disso, o relacionamento entre tabelas da empresa só pode estar dentro do schema da empresa, caso contrário a tabela de join teria de ter uma coluna para cada tabela de schema diferente. Completamente impossível.}}		Além disso, o relacionamento entre tabelas da empresa só pode estar dentro do schema da empresa, caso contrário a tabela de join teria de ter uma coluna para cada tabela de schema diferente. Completamente impossível.}}

	=== Composição 1:1 ===		== Composição 1:1 ==


Linha 178:		Linha 186:
	* '''targetRelationship''' - Classe do objeto utilizado na contra-parte. Normalmente a mesma classe passada no "generics" da coleção. '''Quando não é uma coleção de objeto, este atributo pode ser omitido e será usado o próprio tipo do Field declarado na classe'''. Neste caso o FileVO.		* '''targetRelationship''' - Classe do objeto utilizado na contra-parte. Normalmente a mesma classe passada no "generics" da coleção. '''Quando não é uma coleção de objeto, este atributo pode ser omitido e será usado o próprio tipo do Field declarado na classe'''. Neste caso o FileVO.

	=== Composição 1:N ===		== Composição 1:N ==

	=== Composição N:N ===		== Composição N:N ==

	O BIS não permite esse tipo de composição. Isso porque esse relacionamento indica o reaproveitamento dos objetos filhos por outros pais. Neste caso o objeto filho deve ter sua "autonomia" e viver independente do pai. Casos como esses devem ser transformados em Associação N:N.		O BIS não permite esse tipo de composição. Isso porque esse relacionamento indica o reaproveitamento dos objetos filhos por outros pais. Neste caso o objeto filho deve ter sua "autonomia" e viver independente do pai. Casos como esses devem ser transformados em Associação N:N.

Rodrigogml em 20h26min de 13 de fevereiro de 2019

2019-02-13T20:26:38Z

← Edição anterior		Edição das 20h26min de 13 de fevereiro de 2019
Linha 1:		Linha 1:
	TA persistência do BIS é automatizada como um sistema de ORM automático, mas melhor definido para as necessidades de Patterns do BIS. Gerando menos problemas de persistência, mais autonomia no desenvolvimento e praticidade na maior parte das tarefas que envolvem o banco de dados.		A persistência do BIS é automatizada como um sistema de ORM automático, mas melhor definido para as necessidades de Patterns do BIS. Gerando menos problemas de persistência, mais autonomia no desenvolvimento e praticidade na maior parte das tarefas que envolvem o banco de dados.

	O principal objetivo do BISDAO é receber objetos e persisti-lo (inserindo/atualizando), exclui-lo ou encontrar os objetos no banco de dados automaticamente. Abstraindo a questão objeto x relacional do banco de dados, e diminuindo (ou eliminando na maioria dos casos) a necessidade de implementação códigos SQL pelo desenvolvedor.		O principal objetivo do BISDAO é receber objetos e persisti-lo (inserindo/atualizando), exclui-lo ou encontrar os objetos no banco de dados automaticamente. Abstraindo a questão objeto x relacional do banco de dados, e diminuindo (ou eliminando na maioria dos casos) a necessidade de implementação códigos SQL pelo desenvolvedor.

Rodrigogml em 20h26min de 13 de fevereiro de 2019

2019-02-13T20:26:22Z

← Edição anterior		Edição das 20h26min de 13 de fevereiro de 2019
Linha 1:		Linha 1:
	A persistência do BIS é automatizada como um sistema de ORM automático, mas melhor definido para as necessidades de Patterns do BIS. Gerando menos problemas de persistência, mais autonomia no desenvolvimento e praticidade na maior parte das tarefas que envolvem o banco de dados.		TA persistência do BIS é automatizada como um sistema de ORM automático, mas melhor definido para as necessidades de Patterns do BIS. Gerando menos problemas de persistência, mais autonomia no desenvolvimento e praticidade na maior parte das tarefas que envolvem o banco de dados.

	O principal objetivo do BISDAO é receber objetos e persisti-lo (inserindo/atualizando), exclui-lo ou encontrar os objetos no banco de dados automaticamente. Abstraindo a questão objeto x relacional do banco de dados, e diminuindo (ou eliminando na maioria dos casos) a necessidade de implementação códigos SQL pelo desenvolvedor.		O principal objetivo do BISDAO é receber objetos e persisti-lo (inserindo/atualizando), exclui-lo ou encontrar os objetos no banco de dados automaticamente. Abstraindo a questão objeto x relacional do banco de dados, e diminuindo (ou eliminando na maioria dos casos) a necessidade de implementação códigos SQL pelo desenvolvedor.

Rodrigogml: /* BISMetaCollection */

2018-10-05T17:56:32Z

BISMetaCollection

@@ Linha 282: / Linha 282: @@
 == BISMetaCollection ==
 <pre>
@@ Linha 312: / Linha 322: @@
 --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 </pre>

Rodrigogml: /* Implementação */

2018-10-03T21:37:17Z

Implementação

← Edição anterior		Edição das 21h37min de 3 de outubro de 2018
Linha 198:		Linha 198:

	Aqui temos um exemplo de mapeamento criado ao tentar buscar um objeto '''BISUserVO''' incluindo as empresas '''BISCompanyVO''':		Aqui temos um exemplo de mapeamento criado ao tentar buscar um objeto '''BISUserVO''' incluindo as empresas '''BISCompanyVO''':

			[[File:AssociacaoNN.png\|center\|frame\|Associação ManyToMany entre BISCompanyVO e BISUserVO]]

	<pre>		<pre>

Rodrigogml: /* Composição N:N */

2018-10-03T21:32:02Z

Composição N:N

Mostrar alterações

Rodrigogml: /* Composição 1:1 */

2018-07-24T16:24:21Z

Composição 1:1

← Edição anterior		Edição das 16h24min de 24 de julho de 2018
Linha 165:		Linha 165:
	* '''targetRelationship''' - Classe do objeto utilizado na contra-parte. Normalmente a mesma classe passada no "generics" da coleção. '''Quando não é uma coleção de objeto, este atributo pode ser omitido e será usado o próprio tipo do Field declarado na classe'''. Neste caso o FileContentVO.		* '''targetRelationship''' - Classe do objeto utilizado na contra-parte. Normalmente a mesma classe passada no "generics" da coleção. '''Quando não é uma coleção de objeto, este atributo pode ser omitido e será usado o próprio tipo do Field declarado na classe'''. Neste caso o FileContentVO.


			{{java\|FileContentVO\|<syntaxhighlight lang="java">
			@BISMetaRelationshipField(relationship = RelationshipTypes.PARENT_ASSOCIATION, column = "k_file_id")
			private FileVO fileVO = null;
			</syntaxhighlight>}}


			Sendo os atributos:
			* '''relationship''' - Definido como PARENT_ASSOCIATION para indicar que esta entidade é a filha de uma composição (objeto submisso) e que este field se relaciona com o objeto pai.
			* '''column''' - nome da coluna que tem o ID da entidade associada. '''Utilizado somente se a coluna com o ID estiver na tabela desta entidade'''.
			* '''columnMapped''' - nome da coluna que tem o nosso ID na tabela da contra-parte. '''Utilizado somente se a coluna com o ID desta entidade (FK) estiver na tabela da entidade associada'''.
			* '''targetRelationship''' - Classe do objeto utilizado na contra-parte. Normalmente a mesma classe passada no "generics" da coleção. '''Quando não é uma coleção de objeto, este atributo pode ser omitido e será usado o próprio tipo do Field declarado na classe'''. Neste caso o FileVO.

	=== Composição 1:N ===		=== Composição 1:N ===

Rodrigogml: /* Mapeamento do Relacionamento */

2018-07-24T16:22:14Z

Mapeamento do Relacionamento

← Edição anterior		Edição das 16h22min de 24 de julho de 2018
Linha 100:		Linha 100:

	{{java\|FileVO\|<syntaxhighlight lang="java">		{{java\|FileVO\|<syntaxhighlight lang="java">
	@BISMetaRelationshipField(column = "k_company_id"~~, required = true~~, relationship = RelationshipTypes.ASSOCIATION, ...)		@BISMetaRelationshipField(column = "k_company_id", relationship = RelationshipTypes.ASSOCIATION, ...)
	private BISCompanyVO companyVO = null;		private BISCompanyVO companyVO = null;
	</syntaxhighlight>}}		</syntaxhighlight>}}
Linha 109:		Linha 109:
	* '''column''' - nome da coluna que tem o ID da entidade associada. '''Utilizado somente se a coluna com o ID estiver na tabela desta entidade'''.		* '''column''' - nome da coluna que tem o ID da entidade associada. '''Utilizado somente se a coluna com o ID estiver na tabela desta entidade'''.
	* '''columnMapped''' - nome da coluna que tem o ID do objeto da contra-parte. '''Utilizado somente se a coluna com o ID desta entidade (FK) estiver na tabela da entidade associada'''.		* '''columnMapped''' - nome da coluna que tem o ID do objeto da contra-parte. '''Utilizado somente se a coluna com o ID desta entidade (FK) estiver na tabela da entidade associada'''.
	* '''~~targetRelacionship~~''' - Classe do objeto utilizado na contra-parte. Normalmente a mesma classe passada no "generics" da coleção. '''Quando não é uma coleção de objeto, este atributo pode ser omitido e será usado o próprio tipo do Field declarado na classe'''. Neste caso o BISCompanyVO.		* '''targetRelationship''' - Classe do objeto utilizado na contra-parte. Normalmente a mesma classe passada no "generics" da coleção. '''Quando não é uma coleção de objeto, este atributo pode ser omitido e será usado o próprio tipo do Field declarado na classe'''. Neste caso o BISCompanyVO.

	=== Associação N:N ===		=== Associação N:N ===
Linha 135:		Linha 135:
	* '''column''' - nome da coluna que tem o ID da entidade onde está a declaração.		* '''column''' - nome da coluna que tem o ID da entidade onde está a declaração.
	* '''columnMapped''' - nome da coluna que tem o ID do objeto da contra-parte.		* '''columnMapped''' - nome da coluna que tem o ID do objeto da contra-parte.
	* '''~~targetRelacionship~~''' - Classe do objeto utilizado na contra-parte. Normalmente a mesma classe passada no "generics" da coleção.		* '''targetRelationship''' - Classe do objeto utilizado na contra-parte. Normalmente a mesma classe passada no "generics" da coleção.


Linha 145:		Linha 145:

	=== Composição 1:1 ===		=== Composição 1:1 ===


			[[File:Composicao11.png\|center\|frame\|Composição OneToOne entre FileVO e FileContentVO]]


			A composição 1:1 tem basicamente a função de separar uma coleção de dados do objeto principal, podendo deixar o objeto com os dados principais mais leve. Ou separar uma coleção de dados não obrigatórios. No exemplo abaixo, separamos o conteúdo do arquivo (FileContentVO) dos dados do arquivo (FileVO). Assim quando precisamos recuperar as informações sobre os arquivos do banco não temos de obter todo o conteúdo do arquivo deixando uma conexão pesada e muitos dados na memória.


			{{java\|FileVO\|<syntaxhighlight lang="java">
			@BISMetaRelationshipField(columnMapped = "k_file_id", relationship = RelationshipTypes.COMPOSITION, ...)
			private FileContentVO fileContentVO = null;
			</syntaxhighlight>}}


			Sendo os atributos:
			* '''relationship''' - Definido como COMPOSITION para indicar a composição (tanto para 1:N quanto 1:1).
			* '''column''' - nome da coluna que tem o ID da entidade associada. '''Utilizado somente se a coluna com o ID estiver na tabela desta entidade'''.
			* '''columnMapped''' - nome da coluna que tem o nosso ID na tabela da contra-parte. '''Utilizado somente se a coluna com o ID desta entidade (FK) estiver na tabela da entidade associada'''.
			* '''targetRelationship''' - Classe do objeto utilizado na contra-parte. Normalmente a mesma classe passada no "generics" da coleção. '''Quando não é uma coleção de objeto, este atributo pode ser omitido e será usado o próprio tipo do Field declarado na classe'''. Neste caso o FileContentVO.


	=== Composição 1:N ===		=== Composição 1:N ===

Rodrigogml: /* Associação 1:N */

2018-07-24T16:15:34Z

Associação 1:N

← Edição anterior		Edição das 16h15min de 24 de julho de 2018
Linha 91:		Linha 91:

	=== Associação 1:N ===		=== Associação 1:N ===


	[[File:Associacao1N.png\|center\|frame\|Associação OneToMany entre BISCompanyVO e BISFileVO]]		[[File:Associacao1N.png\|center\|frame\|Associação OneToMany entre BISCompanyVO e BISFileVO]]


	A associação 1:N do exemplo é unilateral, já que só o FileVO tem conhecimento do vínculo. A descrição do mapeamento feito no FileVO é a mesma utilizada em uma associação 1:1.		A associação 1:N do exemplo é unilateral, já que só o FileVO tem conhecimento do vínculo. A descrição do mapeamento feito no FileVO é a mesma utilizada em uma associação 1:1.


	{{java\|FileVO\|<syntaxhighlight lang="java">		{{java\|FileVO\|<syntaxhighlight lang="java">
Linha 100:		Linha 103:
	private BISCompanyVO companyVO = null;		private BISCompanyVO companyVO = null;
	</syntaxhighlight>}}		</syntaxhighlight>}}


	Sendo os atributos:		Sendo os atributos:
Linha 106:		Linha 110:
	* '''columnMapped''' - nome da coluna que tem o ID do objeto da contra-parte. '''Utilizado somente se a coluna com o ID desta entidade (FK) estiver na tabela da entidade associada'''.		* '''columnMapped''' - nome da coluna que tem o ID do objeto da contra-parte. '''Utilizado somente se a coluna com o ID desta entidade (FK) estiver na tabela da entidade associada'''.
	* '''targetRelacionship''' - Classe do objeto utilizado na contra-parte. Normalmente a mesma classe passada no "generics" da coleção. '''Quando não é uma coleção de objeto, este atributo pode ser omitido e será usado o próprio tipo do Field declarado na classe'''. Neste caso o BISCompanyVO.		* '''targetRelacionship''' - Classe do objeto utilizado na contra-parte. Normalmente a mesma classe passada no "generics" da coleção. '''Quando não é uma coleção de objeto, este atributo pode ser omitido e será usado o próprio tipo do Field declarado na classe'''. Neste caso o BISCompanyVO.


	=== Associação N:N ===		=== Associação N:N ===

Rodrigogml: /* Mapeamento do Relacionamento */

2018-07-24T16:11:23Z

Mapeamento do Relacionamento

← Edição anterior		Edição das 16h11min de 24 de julho de 2018
Linha 91:		Linha 91:

	=== Associação 1:N ===		=== Associação 1:N ===

			[[File:Associacao1N.png\|center\|frame\|Associação OneToMany entre BISCompanyVO e BISFileVO]]

			A associação 1:N do exemplo é unilateral, já que só o FileVO tem conhecimento do vínculo. A descrição do mapeamento feito no FileVO é a mesma utilizada em uma associação 1:1.

			{{java\|FileVO\|<syntaxhighlight lang="java">
			@BISMetaRelationshipField(column = "k_company_id", required = true, relationship = RelationshipTypes.ASSOCIATION, ...)
			private BISCompanyVO companyVO = null;
			</syntaxhighlight>}}

			Sendo os atributos:
			* '''relationship''' - Definido como ASSOCIATION para indicar a associação (tanto para 1:N quanto 1:1).
			* '''column''' - nome da coluna que tem o ID da entidade associada. '''Utilizado somente se a coluna com o ID estiver na tabela desta entidade'''.
			* '''columnMapped''' - nome da coluna que tem o ID do objeto da contra-parte. '''Utilizado somente se a coluna com o ID desta entidade (FK) estiver na tabela da entidade associada'''.
			* '''targetRelacionship''' - Classe do objeto utilizado na contra-parte. Normalmente a mesma classe passada no "generics" da coleção. '''Quando não é uma coleção de objeto, este atributo pode ser omitido e será usado o próprio tipo do Field declarado na classe'''. Neste caso o BISCompanyVO.


	=== Associação N:N ===		=== Associação N:N ===