Carregando o Modelo DataGraph do Virtual member manager

O virtual member manager suporta duas maneiras de carregar o modelo DataGraph na memória: carregamento dinâmico e estático. Cada método tem vantagens.

Carregamento Dinâmico

Carregamento dinâmico significa que o modelo DataGraph está carregado na memória como um modelo ECore no tempo de execução a partir dos arquivos XSD através do XSDEcoreBuilder.

As vantagens desse método são:
Estende facilmente
Diferente do carregamento estático, o carregamento dinâmico não precisa gerar código do modelo estático. Todas as definições de esquema são definidas e carregadas a partir do arquivo XSD.
Permite alterações no esquema interno do virtual member manager
Novos tipos de propriedade podem ser incluídos nos tipos de entidade integrada do virtual member manager através do arquivo wimxmlextension.xml.
Suporta inclusão do novo esquema no tempo de execução
Exploradores podem chamar a API createSchema no tempo de execução para criar novos tipos de entidades e de propriedade.
As desvantagens desse método são:
Carrega mais lentamente
O tempo que leva para carregar o arquivo XSD é mais longo que o carregamento do código do modelo estático. O processo de carregamento ocorre toda a vez que o virtual member manager inicia.
Não é possível utilizar tipos nativos
Nessa abordagem, os clientes não podem lançar os Objetos de Dados para os tipos nativos (como PersonAccount, Group) e usar os métodos nativos desses tipos. Por exemplo, os clientes só podem usar o método setString(“givenname”, “Smith”) de Objeto de Dados para configurar o nome, mas não podem usar setGivenname(“Smith”) de PersonAccount.
Tem desempenho de tempo de execução mais lento
O desempenho de SDO utilizando carregamento dinâmico é mais lento que o modelo estático.

Carregamento Estático

Carregamento estático significa que o código do modelo estático é gerado através da geração de códigos EMF (Eclipse Modeling Framework) no tempo do desenvolvimento. O código do modelo é uma implementação de EMF do SDO. O aplicativo SDO utiliza o pacote do código do modelo gerado. Essa abordagem salva o tempo utilizado para carregar o modelo a partir dos arquivos XSD no carregamento dinâmico. Ele também permite que os usuários lancem os DataObjects para tipos de objetos nativos para aprimorar o desempenho do tempo de execução.

As vantagens desse método são:
Carrega mais rápido
Comparado com o modelo de carregamento dos arquivos XSD, o modelo de carregamento a partir do código do modelo estático é mais rápido. Isso torna mais curta a hora de início do virtual member manager.
Permite que os exploradores utilizem tipos nativos
O objeto de dados pode ser lançado para tipos nativos (como PersonAccount, Group) e usar os métodos nativos desses tipos. Por exemplo, o objeto de dados pode ser lançado para PersonAccount e o método “setGivenname” pode ser usado para configurar a propriedade “givenname”.
Tem desempenho de tempo de execução melhor
Utilizando os tipos e métodos nativos, o desempenho de tempo de execução de SDO é melhor do que o método de carregamento dinâmico.
As desvantagens desse método são:
Estende menos facilmente
A extensão de esquema precisa gerar códigos de modelos estáticos através do ambiente de desenvolvimento RAD ou Eclipse. Os exploradores do virtual member manager precisam ter conhecimento do Esquema EMF, SDO e XML para fazer a extensão.
Alterar para o esquema interno do virtual member manager é mais difícil
Se você quiser incluir novos tipos de propriedade nos tipos de entidade integrados do gerenciador de membro virtual (como PersonAccount e Group), será necessário modificar diretamente o arquivo wimdomain.xsd e gerar novamente o código do modelo estático do gerenciador de membro virtual.
Não suporta inclusão do novo esquema no tempo de execução
Porque o código de modelo gerado é fixo, você não pode estender o esquema no tempo de execução do virtual member manager.


Termos de uso | Feedback