BISVO - Histórico de revisão

Rodrigogml: /* O Paradoxo do Equals */

2020-10-12T17:42:26Z

O Paradoxo do Equals

← Edição anterior		Edição das 17h42min de 12 de outubro de 2020
Linha 73:		Linha 73:
	Os passos normais são, buscar no banco de dados a lista de caixas cadastradas e colocar na tabela. Em seguida buscar a configuração salva e chamar o comando tipo "setSelected(...)" na tabela que seja capaz de selecionar o objeto passado. O problema é que embora na lista tenha o objeto que desejamos selecionar o Vaadin vai procurar o objeto que mandamos selecionar ne lista de objetos existentes através do equals(). E nenhum será igual. Uma vez que o objeto na lista e o objeto da seleção foram buscados no banco de dados em momentos diferentes e são dois objetos distintos na memória, fazendo com que o equals retorne falso.		Os passos normais são, buscar no banco de dados a lista de caixas cadastradas e colocar na tabela. Em seguida buscar a configuração salva e chamar o comando tipo "setSelected(...)" na tabela que seja capaz de selecionar o objeto passado. O problema é que embora na lista tenha o objeto que desejamos selecionar o Vaadin vai procurar o objeto que mandamos selecionar ne lista de objetos existentes através do equals(). E nenhum será igual. Uma vez que o objeto na lista e o objeto da seleção foram buscados no banco de dados em momentos diferentes e são dois objetos distintos na memória, fazendo com que o equals retorne falso.

	Por ser uma operação "dentro" do Vaadin, não temos como alterar o modo como ele compara o mesmo objeto. Para casos como esse a solução é encapsular o objeto dentro de outro e dentro deste implementamos o Equals da maneira como achamos conveniente. Como por exemplo comparando a classe e o ID dos objeto, uma vez que todos os objetos de mesma classe tem IDs únicos. Para essa solução conheça o [[GhostVO (GVO)]].		Por ser uma operação "dentro" do Vaadin, não temos como alterar o modo como ele compara o mesmo objeto. Para casos como esse a solução é encapsular o objeto dentro de outro e dentro deste implementamos o Equals da maneira como achamos conveniente. Como por exemplo comparando a classe e o ID dos objeto, uma vez que todos os objetos de mesma classe tem IDs únicos. Para essa solução conheça o [[GhostVO]] (GVO).

	Para objetos não persistidos em banco de dados o equals precisa ser mais elaborado já que não teremos o ID definido.		Para objetos não persistidos em banco de dados o equals precisa ser mais elaborado já que não teremos o ID definido.

Rodrigogml: /* O Clone Recursivo */

2020-10-12T17:39:42Z

O Clone Recursivo

← Edição anterior		Edição das 17h39min de 12 de outubro de 2020
Linha 60:		Linha 60:

	{{stop\|Limitação do Clone Recursivo\|O método conhece alguns objetos de coleção mais utilizados no BIS, como ArrayList, LinkedList, HashMap, etc.. Caso seja utilizado algum tipo de objeto diferente dos comummente utilizados, o método precisa ser verificado e talvez ter o suporte à esses objetos acrescentado.}}		{{stop\|Limitação do Clone Recursivo\|O método conhece alguns objetos de coleção mais utilizados no BIS, como ArrayList, LinkedList, HashMap, etc.. Caso seja utilizado algum tipo de objeto diferente dos comummente utilizados, o método precisa ser verificado e talvez ter o suporte à esses objetos acrescentado.}}

			= O Paradoxo do Equals =

			O BISVO e '''todos os seus descendentes''' devem manter a implementação do do equals inalterada para utilizar todos os serviços do BISFW. Muitos dos serviços que o BISFW oferece utiliza o a implementação do equals padrão (que verifica se é o mesmo objeto na memória) para garantir que não estamos em uma iteração infinita quando os VOs tem uma referência cíclica (como objetos da relação pai e filho).

			O problema é que em algumas situações esse equals precisaria de uma implementação diferente. Um exemplo conhecido é a biblioteca utiliza na UI, o Vaadin.

			Imagine o seguinte cenário:
			* temos uma tela de configuração de caixa e-mail padrão do sistema. Caixa pela qual o sistema enviará seus e-mails automáticos.
			* Agora imagine que ao abrir essa tela vamos exibir a lista de caixas disponíveis em uma tabela do Vaadin. E por óbvio, já vamos exibir selecionada a caixa atualmente configurada.

			Os passos normais são, buscar no banco de dados a lista de caixas cadastradas e colocar na tabela. Em seguida buscar a configuração salva e chamar o comando tipo "setSelected(...)" na tabela que seja capaz de selecionar o objeto passado. O problema é que embora na lista tenha o objeto que desejamos selecionar o Vaadin vai procurar o objeto que mandamos selecionar ne lista de objetos existentes através do equals(). E nenhum será igual. Uma vez que o objeto na lista e o objeto da seleção foram buscados no banco de dados em momentos diferentes e são dois objetos distintos na memória, fazendo com que o equals retorne falso.

			Por ser uma operação "dentro" do Vaadin, não temos como alterar o modo como ele compara o mesmo objeto. Para casos como esse a solução é encapsular o objeto dentro de outro e dentro deste implementamos o Equals da maneira como achamos conveniente. Como por exemplo comparando a classe e o ID dos objeto, uma vez que todos os objetos de mesma classe tem IDs únicos. Para essa solução conheça o [[GhostVO (GVO)]].

			Para objetos não persistidos em banco de dados o equals precisa ser mais elaborado já que não teremos o ID definido.

Rodrigogml: /* A mudança e o BIS */

2019-05-19T18:13:01Z

A mudança e o BIS

@@ Linha 15: / Linha 15: @@
-== A mudança e o BIS ==
+== A Mudança e o BIS ==
 Com o tempo a utilização do termo VO passou a indicar objetos maiores capaz de guardar uma coleção de informações/atributos de um determinado objeto, bem como a serem transmitidos entre as camadas e rede. Ou seja, popularmente chama-se de VO os objetos acima chamados de DTO.
@@ Linha 26: / Linha 26: @@
 '''As vantagens''' de ter um único objeto, primeiro é não ter que implementar várias classes (um Bean, Um VO, um TO, etc) que representam a mesma coisa. Ganhamos no tempo de desenvolvimento, manutenção do objeto e de não ter que criar "conversores" que passam os dados de um objeto para outro.
 '''As desvantagens''' é que passamos a ter limitações na criação dos objetos, como por exemplo, sendo o mesmo objeto usado em toda a aplicação, o objeto não pode simplesmente ganhar atributos por ser conveniente para a cada de apresentação ou para a camada de persistência. Em resumo, um '''BISVO''' deve conter apenas os atributos que realmente descrevem o objeto e nunca atributos convenientes ou temporários para exibição ou de processamento. (Nestes casos recomenda-se a criação de outro BEAN que encapsule o VO).

Rodrigogml: Criou página com 'Todo a estrutura do BIS é baseada na manipulação dos objetos do tipo BISVO. Entender a base da estrutura do VO e seu funcionamento é o primeiro passo para desenvolver bem...'

2019-05-19T17:57:45Z

Criou página com 'Todo a estrutura do BIS é baseada na manipulação dos objetos do tipo BISVO. Entender a base da estrutura do VO e seu funcionamento é o primeiro passo para desenvolver bem...'

Página nova

Todo a estrutura do BIS é baseada na manipulação dos objetos do tipo BISVO. Entender a base da estrutura do VO e seu funcionamento é o primeiro passo para desenvolver bem no BIS.

= Introdução aos Objetos de Dados dos Patterns Java =

Para entender o VO do BIS, vamos entender primeiro a definição dos objetos como definidos nas documentações dos patterns de desenvolvimento do Java:

* '''Java Beans''' - O java Bean é uma classe simples utilizada apenas para carregar um conjunto de dados. Esta deve seguir as seguintes regras:
** Conter um construtor publico padrão - isto é, um construtor que não receba nenhum parâmetro.
**: O objetivo dessa regra é permitir que os frameworks possam instanciar o objeto facilmente, sem necessariamente conhece o objeto e saber que dados passar no construtor.
** Seus atributos devem ser acessíveis através de métodos GET e SET. E preferencialmente ter seus atributos privados para evitar um acesso direto.
** Sua classe deve ser serializável, isto é, implementar ou extender alguma classe que implemente a interface 'Serializable' do java.
**: Isso permite que o objeto seja convertido em vários outros tipos de estrutura (como XML por exemplo) e salvos ou transmitidos para outros plataformas, frameworks, computadores, etc. e ser retornado em um objeto de forma fácil.
* '''Value Object''' - O Value Object (VO) era um termo inicialmente utilizado para indicar um objeto capaz de guardar uma pequena quantidade de informação. Como o objeto/classe Integer ou String do Java. Além disso, um VO deveria ser imutável. Toda vez que seu dado precisasse ser alterado, o objeto deveria ser descartado e um novo construído, exatamente como as classes do Java citadas.
* '''Data Transport Object''' - O Data Transfer Object (DTO) é o objeto capaz de carregar as informações através da rede, ou mesmo entre as camadas (sendo que as camadas podem estar em diferentes máquinas). Ou seja, o DTO é o objeto que carrega os VOs entre as camadas ou sistema distintos. Os DTO também são conhecidos só por TO (Transfer Objects).

== A mudança e o BIS ==

Com o tempo a utilização do termo VO passou a indicar objetos maiores capaz de guardar uma coleção de informações/atributos de um determinado objeto, bem como a serem transmitidos entre as camadas e rede. Ou seja, popularmente chama-se de VO os objetos acima chamados de DTO.

No BIS chamamos o objeto de VO e juntamos todas as funcionalidade em um objeto único! Assim, o VO do BIS é:
* o objeto capaz de representar uma pessoa, uma venda, uma nota, um produto e assim por diante (como um VO ou Java Bean);
* é utilizado e transferido desde a camada de persistência até a camada de apresentação (como o DTO);
* tem as mesmas obrigações que o Java Bean (de construtor e acesso dos atributos por GET e SET, devendo estes métodos seguir a convenção de nomes definidos pela Sun);
* devem obrigatoriamente estender a classe '''BISVO'''.

'''As vantagens''' de ter um único objeto, primeiro é não ter que implementar várias classes (um Bean, Um VO, um TO, etc) que representam a mesma coisa. Ganhamos no tempo de desenvolvimento, manutenção do objeto e de não ter que criar "conversores" que passam os dados de um objeto para outro.
'''As desvantagens''' é que passamos a ter limitações na criação dos objetos, como por exemplo, sendo o mesmo objeto usado em toda a aplicação, o objeto não pode simplesmente ganhar atributos por ser conveniente para a cada de apresentação ou para a camada de persistência. Em resumo, um '''BISVO''' deve conter apenas os atributos que realmente descrevem o objeto e nunca atributos convenientes ou temporários para exibição ou de processamento. (Nestes casos recomenda-se a criação de outro BEAN que encapsule o VO).