Novo Modelo do Novo Modelo

Para evitar a utilização do DMA como factory, decidimos alterar o modelo, com a alteração da derivação para composição
.:Modelo 2


O aparecimento de um Parent na PiscoDataRow deve-se ao facto de decidirmos alterar tambem o modo como os objectos são armazenados em base de dados para permitir utilizar relações directamente no SGBD evitando o processamento para manter a coerência entre os dados.

Desta forma o novo modelo relacional é um espelho do modelo hierárquico

Novo Modelo de Dados
Alterando a filosofia de criação de objectos pelo DMA, deve ser este a definir a forma como estes são armazenados e não o serviço. Para tal decidimos criar um identificador único, por serviço, que identifica inequivocamente cada registo.
Os objectos são armazenados em tabelas com todas as propriedades, próprias e herdadas.
.:Exemplo


.: Problemas
- Relações entre objectos, pelo facto de não se ter uma dependência hierarquica não permite manter uma relação para um tipo base, por exemplo MyObject, porque esta pode ser instânciada por um objecto MyObject_A ou MyObject_B.

.:Soluções
- Criação de tabelas de relação.
Criar uma tabela que associa o objecto que referencia com o objecto referenciado. É necessário criar também uma tabela por cada objecto derivado deste. Origina uma explosão de tabelas, sempre que se acrescenta um tipo derivado de um tipo existente é necessário criar tantas tabelas quantas as referências que existão para ele e para qualquer uma das classes base.
- Criar uma tabela global de relações que associa dois quaisquer objectos. Fica a cargo do DMA verificar essas relações.

Novo Modelo

Aproveitando o facto de serem utilizados DataSet´s para suportar os dados,foi escolhido o modelo descrito no "Pragmatic ADO.NET" de Shawn Wildermuth, que consiste na simplificação da camada dos objectos de negócio.
- Mapeamento directo do modelo relacional para o modelo hierarquico, evitando a transformação.
- Ler e gravar esses objectos na base de dados.
- Adicionar lógica de negócia aos objectos.

.:Modelo



Desta forma os objectos são guardados directamente na base de dados.
As propriedades de tipos primitivos são convertidos directamente do tipo SQL da coluna correspondente.
As propriedades de tipos compostos, referências para objectos e listas de objectos, só são criadas quando acedidas a primeira vez.

.:Conclusão
- Coloca todo o processamento no DataModelAdapter fornecido.
- Não é necessário de criar todas as dependências na instanciação do objecto, evitando a necessidade de controlo de referências circulares, e de carregar todos esses objectos em memória, caso não sejam necessários.
- Obriga que o criador do serviço altere as suas entidades para obedecer a este modelo.
- Não evita a utilização de factory para a criação de objectos, visto que segundo a filosofia do ADO .NET não é possível a criação de DataRow's de forma directa.

Conclusões 2
A implementação desta solução para objectos com propriedades de tipos compostos como referências para outros objectos e listas de objectos, mostrou ser bastante complexo.

.:Problemas
- Criação dos objectos dependentes, terá de ser o transformer do objecto a criar as depedências do objecto.

- Possibilidade de ocurrência de referências circulares.
O controlo de referências circulares não é trivial. Como cada transformer é utilizado para um tipo especifico, poderão ser chamados vários transformers na criação de um único objecto. Seria necessário criar um contexto dentro do qual são invocados os transformers.

- Dados em memória.
Dado o objecto criado não ter noção da sua criação pelo transformer, é obrigatório que o objecto e suas dependências estejam criadas aquando da sua utilização, o que no limite pode obrigar a colocar toda a base de dados em memória.

- Factories de objectos.
O serviço é obrigado a invocar o dma sempre que pretendia criar um novo objecto.

Mediante estes problemas, em especial a complexidade que é delegada aos transformers, cuja responsabilidade da implementação pertence ao criador do serviço, esta solução foi posta de parte e partimos em busca de uma outra solução.

Conclusões
Concluimos a implementação desta solução no Serviço de Contactos, com a implementação do SimpleContact. Verificamos a validade da mesma para objectos compostos por propriedades de tipos primitivos (int, string, ...).

Transformação

O problema que agora se levanta é como realizar a transformação.

A solução apontada anteriormente definia um DataModelAdapter base, do qual os serviços criavam uma versão especializada para transformar os objectos em rows e vice-versa, o que torna um pouco confuso o facto de o adapter ter de saber todas essas transformações.

A ideia é a utilização de objectos especializados para cada objecto a transformar, de modo a serem usados pelo adapter.

Manuseamento dos dados(Serviço de Gestão de Dados)

- inserir, ler e actualizar dados.
- transformação de modelo relacional para modelo de objectos.
- garantir coerência das referências entre objectos.

.:Modelo proposto


Inserção/Actualização:
O serviço cria um Objecto que é transformado pelo Adapter numa Row, o Manager acrescenta um Header com informação de sistema e envia ao SGBD.

Leitura:
O Manager obtém a Row do SGBD, retira o Header e devolve-a ao Adapter que transforma num Objecto preenchendo as suas propriedades.

.:Observações
- Para utilizar o DataManager é necessário fornecer um o Adapter que tenha conhecimento sobre os objectos a persistir. Este Adapter também é responsável por gerir a coerência entre objectos.
- O Manager fica apenas com o papel de intermediário, impondo regras de acesso, mas sem controlo dos objectos.

.:Sugestão
Juntar as funcionalidades do Manager e do Adapter numa única entidade, responsável pelo controlo de acesso e transformação, com cache local dos objectos já requisitados.
Para tal utiliza-se o padrão GoF Template implementando o algoritmos de acesso e transformação num Adapter base. Cada serviço cria um Adapter especializado adicionando ao algoritmo a informação especifica para a tranformação do objecto.