RoleInterfaces based ORM

[Daniel Moreira Yokoyama]

Pessoal,

 

Já faz um tempo que eu estava me cobrando enviar esta dúvida aqui.

 

Eu tenho o costume de fazer a camada de acesso a dados baseada em RoleInterfaces. Assim:

 

Num sistema, por exemplo, de automação de força de vendas pra indústria farmacêutica, os representantes visitam médicos e farmácias.

 

Em alguns casos eu só quero trabalhar com médicos, outros só com farmácias, outros com ambos. Ainda em outros casos, o laboratório tem produtos segmentados para ortodontia ou oftamologia e, apesar do oftamologista também ser médico, ele quer que seja tratado como um cara separado em alguns aspectos e em outros como um igual entre médicos e farmácias.

 

A minha solução pra isso pode não ser a melhor de todas, mas atendeu bem:

 

Eu criei uma tabela Master com todos os meus objetos estáticos contendo Id e Nome e ela era a base para as composições com relacionamento 1 para 1 com outras tabelas. As tabelas Medicos e Farmacias, por exemplo, complementavam a tabela Master, mas a tabela Oftamologistas complementava a tabela Medicos, montando assim um esquema bastante flexível. A tabela Visitáveis (um nome horrível, mas nunca encotramos um melhor) tornava todos estes ítens comuns entre eles com os dados de visitas (endereço e agendamento, além de identificar que representante seria responsável pela visita).

 

Para atender este modelo, invés de criarmos repositórios de objetos, criamos RoleInterfaces (IMaster, IMedico, IFarmacia, IOftamologista, IVisitavel) e fizemos com que as entidades fôssem na verdade um agrupamento de interfaces, um Repositório Master servia para todas as entidades, e criava um Repositório para cada tabela, baseado na interface dela. O método Salvar, por exemplo, do repositório Master, recebia objeto de qualquer entidade, instanciava os repositórios e invocava o método Salvar de cada um deles enviando o objeto recebido e estes avaliavam o compatibilidade do objeto com a interface em que eram baseados pra fazer ou não o update na tabela). Já a seleção dos dados era feita enviando ao Repositório Master uma flag de contexto ("Oftamologistas" por exemplo) que identificava o repositório base e o instanciava, este conhecendo seu contexto, fazia os joins necessários (Médicos e Master) ou, no caso de um repositório composto, como Visitáveis, instanciava os outros repositórios, fazia a seleção em cada um deles e devolvia uma lista com o Merge do resultado. Com o tempo otimizamos tudo com lazy loading em alguns pontos, e os repositórios compostos passaram a fazer as seleções em threads separadas e o merge acontecia depois de fazer um join nas threads.

 

Bom, descrito como eu monto meu acesso a dados, alguém aqui saberia me dizer se transpor isso para um ORM é possível sem ferir este modelo? Não conheço o NHibernate mas eu vi que o EF não baseia seus containers em interfaces. Alguém saberia me dizer uma forma de fazê-lo? De preferência, de uma forma que suporte LINQ (já que, o objetivo verdadeiro é este).

 

Opiniões a respeito desta forma de montar o acesso a dados também serão bem vindas: positivas e negativas.

 

Atenciosamente,

Daniel Moreira Yokoyama.
http://halonfullestuse.wordpress.com/

"I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do."
(HAL 9000)

[Alexandre Valente]

Oi Daniel,

Interessante o mecanismo que vc criou. Este é um problema comum (eu tenho algo similar com professores, alunos, pais, administradores etc). A herança clássica não funciona pq às vezes as pessoas podem ser simultaneamente alunos, pais e professores.

Eu acho que vc vai encontrar muita dificuldade pra mapear isto em um ORM padrão como NH ou EF. Nestes casos eu as vezes sigo um mapeamento menos aderente (onde campos existem em entidades mesmo não sendo utilizados em alguns cenários... no seu caso p. ex., pessoas tendo os atributos de oftalmologista).

Existe uma alternativa de se sair para um modelo totalmente denormalizado, em tabelas de id/value (tipo bancos cloud), mas eu não gosto muito da performance disto. 

Se vc achar uma solução simples pra isto nos ORMs por favor não deixe de contribuir pra lista. Como falei, acho que este é um problema muito comum.

abs,

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com

2009/11/30 Daniel Moreira Yokoyama <moreira....@gmail.com>

[Daniel Moreira Yokoyama]

Eu boto fé de que o Entities Framework CodeOnly vai tornar possível esta abordagem. Mas como já foi dito que ele não estará presente na versão final do .Net framework 4.0, e vai levar tempo até ser apresentado oficialmente, eu queria saber se já existe outra alternativa estável.

Atenciosamente,

Daniel Moreira Yokoyama.
http://halonfullestuse.wordpress.com/

"I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do."
(HAL 9000)

2009/11/30 Alexandre Valente <alexandre...@gmail.com>

[Rafael Noronha]

Daniel,

Uma dúvida.

Não teve problemas de performance quebrando os dados destas suas
entidades em diferentes tabelas?
Imagino que não se trate de um requisito *crítico* para este seu
sistema?

[Daniel Moreira Yokoyama]

Rafael,

 

Tivemos essa preocupação a princípio, mas conforme os usuários foram usando o sistema, vimos que o custo da performance não estava impactando na usabilidade.

 

Já cuidamos de fazer algumas coisas de forma assíncrona e com isso tivemos algum ganho, assim como o lazy loading, embora este ainda precise de alguns aprimoramentos. Também estamos pensando no futuro em fazer uma forma de manter as consultas mais acessadas em cache e pesquisamos ainda novas formas de otimizar. Mas, como eu disse, não há nada que impacte de forma dramática.

Atenciosamente,

Daniel Moreira Yokoyama.
http://halonfullestuse.wordpress.com/

"I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do."
(HAL 9000)

2009/11/30 Rafael Noronha <rafan...@gmail.com>

[Daniel Moreira Yokoyama]

Pessoal...

 

Eu não fiquei muito supreso com a falta de respostas para esta thread. A única dúvida que isso me deixa é se ela não foi respondida pela simples falta de interesse ou se realmente ela é uma dúvida pertinente.

 

Se o caso for o primeiro então eu dificilmente vou saber da existência de algum ORM que atenda este modelo. Mas caso for o segundo, então significa que eu consegui levantar uma possível discussão: O que vocês acham do modelo proposto? Alguma crítica? Acham que pode ser uma perda de tempo iniciar o desenvolvimento de um ORM que trabalhe nesse molde? Ainda que ele possa não ser bem aceito na comunidade, ele pode atender alguns casos específicos já que, através do uso de RoleInterfaces você pode separar de forma ainda mais eficiente, ao meu ver, o modelo relacional do modelo de objetos.

 

O que acham?

Atenciosamente,

Daniel Moreira Yokoyama.
http://halonfullestuse.wordpress.com/

"I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do."
(HAL 9000)

2009/11/30 Daniel Moreira Yokoyama <moreira....@gmail.com>

[tucaz]

Daniel,

antes de responder de verdade tenho uma duvida pra ver se entendi seu
cenario. Isso tudo e por questao de permissoes e atributos
diferenciados pra cada tipo de usuario, correto?


On Dec 1, 10:31 am, Daniel Moreira Yokoyama

<moreira.yokoy...@gmail.com> wrote:
> Pessoal...
>
> Eu não fiquei muito supreso com a falta de respostas para esta thread. A
> única dúvida que isso me deixa é se ela não foi respondida pela simples
> falta de interesse ou se realmente ela é uma dúvida pertinente.
>
> Se o caso for o primeiro então eu dificilmente vou saber da existência de
> algum ORM que atenda este modelo. Mas caso for o segundo, então significa
> que eu consegui levantar uma possível discussão: O que vocês acham do modelo
> proposto? Alguma crítica? Acham que pode ser uma perda de tempo iniciar o
> desenvolvimento de um ORM que trabalhe nesse molde? Ainda que ele possa não
> ser bem aceito na comunidade, ele pode atender alguns casos específicos já
> que, através do uso de RoleInterfaces você pode separar de forma ainda mais
> eficiente, ao meu ver, o modelo relacional do modelo de objetos.
>
> O que acham?
>
> Atenciosamente,
>

> Daniel Moreira Yokoyama.http://halonfullestuse.wordpress.com/

>
> "I am putting myself to the fullest possible use, which is all I think that
> any conscious entity can ever hope to do."
> (HAL 9000)
>

> 2009/11/30 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>

>
> > Rafael,
>
> > Tivemos essa preocupação a princípio, mas conforme os usuários foram usando
> > o sistema, vimos que o custo da performance não estava impactando na
> > usabilidade.
>
> > Já cuidamos de fazer algumas coisas de forma assíncrona e com isso tivemos
> > algum ganho, assim como o lazy loading, embora este ainda precise de alguns
> > aprimoramentos. Também estamos pensando no futuro em fazer uma forma de
> > manter as consultas mais acessadas em cache e pesquisamos ainda novas formas
> > de otimizar. Mas, como eu disse, não há nada que impacte de forma dramática.
>
> > Atenciosamente,
>
> > Daniel Moreira Yokoyama.
> >http://halonfullestuse.wordpress.com/
>
> > "I am putting myself to the fullest possible use, which is all I think that
> > any conscious entity can ever hope to do."
> > (HAL 9000)
>

> > 2009/11/30 Rafael Noronha <rafanoro...@gmail.com>

[Daniel Moreira Yokoyama]

Fala tucaz... bem-vindo de volta, by the way...

 

Vamos lá, a questão é bem simples: Tenho um sistema multi-tenant e cada cliente gosta de entrar no site e ver as coisas à sua maneira. Isso já foi motivo de muito rolo e muita gambi alguns anos atrás e nós conseguimos resolver desta maneira. Pense em uma loja virtual onde você tem N tipos de produtos, os quais são produtos mas derivam uns dos outros apesar de não serem exatamente a mesma coisa.

 

Você tem TV, que podem ser de plasma, contendo determinadas características e pode ter TV de LCD, pode ainda ter TV Convencional. Mas você quer que todas elas sejam vistas num mesmo contexto em uma pesquisa, ou seja, se o usuário classificar por preço, você vai mostrar pra ele a lista de TV ordenada por preços independente do tipo de TV que ela seja.

 

Melhor ainda, vou explicar meu case:

O laboratório quer tirar relatórios das visitas, mas um quer ver os mesmos dados seguimentados pelo tipo de target (Médico, Farmácia) enquanto o outro quer que todas as visitas sejam quantificadas em um único contexto independente do tipo do target (médicos e farmácias em uma lista só). Parece até simples, mas cada cliente com suas exigências acabou fazendo a aplicação exigir uma flexibilidade absurda que só foi resolvida da maneira como demonstrei... Tornando os objetos separados mas com possibilidade de se relacionar através de interfaces, e estas por sua vez é que guiam o mapeamento para as tabelas.

Atenciosamente,

Daniel Moreira Yokoyama.
http://halonfullestuse.wordpress.com/

"I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do."
(HAL 9000)

2009/12/1 tucaz <tuc...@gmail.com>

[tucaz]

Por que nao usar simplesmente colunas classificatorias? Exemplo:
tipoPessoa ou coisa parecida. Esse tipo de abordagem geralmente eh
mais simples do que a que voce esta fazendo e acho que mais escalavel,
pois vc nao precisaria criar classes novas pra tipos novos.

Sera que entendi errado ainda?

On Dec 1, 10:56 am, Daniel Moreira Yokoyama

<moreira.yokoy...@gmail.com> wrote:
> Fala tucaz... bem-vindo de volta, by the way...
>
> Vamos lá, a questão é bem simples: Tenho um sistema multi-tenant e cada
> cliente gosta de entrar no site e ver as coisas à sua maneira. Isso já foi
> motivo de muito rolo e muita gambi alguns anos atrás e nós conseguimos
> resolver desta maneira. Pense em uma loja virtual onde você tem N tipos de
> produtos, os quais são produtos mas derivam uns dos outros apesar de não
> serem exatamente a mesma coisa.
>
> Você tem TV, que podem ser de plasma, contendo determinadas características
> e pode ter TV de LCD, pode ainda ter TV Convencional. Mas você quer que
> todas elas sejam vistas num mesmo contexto em uma pesquisa, ou seja, se o
> usuário classificar por preço, você vai mostrar pra ele a lista de TV
> ordenada por preços independente do tipo de TV que ela seja.
>
> Melhor ainda, vou explicar meu case:
> O laboratório quer tirar relatórios das visitas, mas um quer ver os mesmos
> dados seguimentados pelo tipo de target (Médico, Farmácia) enquanto o outro
> quer que todas as visitas sejam quantificadas em um único contexto
> independente do tipo do target (médicos e farmácias em uma lista só). Parece
> até simples, mas cada cliente com suas exigências acabou fazendo a aplicação
> exigir uma flexibilidade absurda que só foi resolvida da maneira como
> demonstrei... Tornando os objetos separados mas com possibilidade de se
> relacionar através de interfaces, e estas por sua vez é que guiam o
> mapeamento para as tabelas.
>
> Atenciosamente,
>

> Daniel Moreira Yokoyama.http://halonfullestuse.wordpress.com/
>
> "I am putting myself to the fullest possible use, which is all I think that
> any conscious entity can ever hope to do."
> (HAL 9000)
>

> 2009/12/1 tucaz <tuca...@gmail.com>

[Daniel Moreira Yokoyama]

Pra falar a verdade, ou você não está entendendo ou conseguiu enxergar algo ridiculamente simples no meu problema que eu fui incapaz de enxergar até agora.

 

Não entendi sua sugestão, incluir uma coluna classificatória, já que as tabelas estão bem separadas. Contudo, as tabelas que reunem os dados comuns, por exemplo, a tabela visitaveis, que liga os médicos e farmácias aos seus dados de visita, por exemplo, agendamento, endereço de visita e os representantes que se encarregam de visitá-los, poderia possuir uma coluna de classificação, embora eu ache que isso acabe sendo uma gambiarra, já que o tipo já pode ser determinado pela chave primária (já que o relacionamento de ambas as tabelas é de 1 para 1).

 

Isso deixou meu código super enxuto, já que o save de um médico faz um save em todos os repositórios envolvidos, cada um fazendo a devida alteração em uma tabela específica (de forma que o repositório médico não precisa conhecer as outras tabelas onde a entidade se relaciona).

 

O repositório Master recebe um objeto no método salvar e simplesmente replica a chamada ao método Salvar dos demais repositórios, cada um se encarrega de verificar se o objeto é aplicável a si (ex: o Repositório Médicos verifica se é uma instancia de IMedico, o de Visitavel verifica se é uma instancia de IVisitavel) e se encarrega de fazer o Save ou simplesmente ignorar a chamada.

 

Só pra você ter idéia minha aplicação quase não faz Joins (exceto Médicos e Farmácias, que são extensão de uma tabela master onde se encontram seus nomes e um bit indicando se estão ativos no banco ou não). É o mais próximo que encontrei de flexibilidade, normalização e ainda por cima não ferir minha orientação a objetos (tipo, um repositório de Médicos tendo que fazer insert em várias tabelas).

 

É claro que existe um certo aprimoramento a ser feito em alguns pontos... e estamos nos preparando pra isso, mas por isso a pergunta sobre existir ou não um framework ORM... por que se formo mexer nesta estrutura iremos aproveitar para torná-la reaproveitável para ser usada em outros projetos.

 

Por fim eu queria entender qual seria o problema de criar classes novas para tipos novos? Principalmente tipos novos que já compartilhem da mesma estrutura (ex: um dos nossos clientes quis começar a fazer visita em Odontologistas, que invés de CRM possuem CRO, e, não só isso, precisam ser enxergados no sistema como distintos dos médicos). Foi uma implementação bem tranquila.

Atenciosamente,

Daniel Moreira Yokoyama.
http://halonfullestuse.wordpress.com/

"I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do."
(HAL 9000)

2009/12/1 tucaz <tuc...@gmail.com>

[tucaz]

Talvez eu esteja vendo de uma maneira extremamente simplista. A ideia
nao deixaria todo o negocio tao bonito quanto o resultado que vc
obteve, mas em suma eh isso mesmo so que ao inves de ter um monte de
tabelas vc teria uma soh com todas as informacoes e usaria a coluna
classificatoria como um enum (?) pra pegar so as informacoes que vc
precisa.

Acho que de qualquer maneira vc teria menos complexidade pq seriam 3
ou 4 menos tabelas e classes pra vc gerenciar.

Nao?

On Dec 1, 1:16 pm, Daniel Moreira Yokoyama

[Daniel Moreira Yokoyama]

Concordo, embora hoje em dia essa complexidade já não existe mais, visto que o mecanismo já funciona.

 

Sei lá, talvez eu levei o conceito de alta coesão e baixo acoplamento muito a sério, rs.

 

Com certeza você não iria gostar muito da idéia de tentar pegar esse esquema e transformar num framework né? rs. Eu mesmo tava na dúvida, mas agora, levando em consideração que nem todos sejam pragmáticos como eu seja algo que somente eu vá usar.

Atenciosamente,

Daniel Moreira Yokoyama.
http://halonfullestuse.wordpress.com/

"I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do."
(HAL 9000)

2009/12/1 tucaz <tuc...@gmail.com>

[Sidney Lima Filho]

Daniel,
   eu acho que não entendi direito, me explica uma coisa eu já faço algo parecido com o antigo LinqToSql. Eu tenho tabela de Pessoas Fisicas que podem ser Contatos, Clientes, Fornecedores, etc.

Seria mais ou menos isso?

Atenciosamente

Sidney Lima Filho
Vivina Softhouse
(0xx21) 2222-7330
(0xx21) 7867-2321
55*10*68934

Conheça -------------------------------------------------------------------------------------------------------------------------------------------------------------------------
http://www.vivina.com.br
http://twitter.com/sidneyfilho

2009/12/1 Daniel Moreira Yokoyama <moreira....@gmail.com>

[Alexandre Valente]

Oi Sindey,

Como vc mapeia isto pra banco de dados? Concordo com o Daniel no sentido de que este problema não tem solução simples (a dele é legal mas não é simples! :-)).

abs

Alexandre Valente

2009/12/1 Sidney Lima Filho <sidney...@vivina.com.br>

[Sidney Lima Filho]

Como no LinqToSql o mapeamento para fazer uma AppDuSoleil, é mais complicado, eu fiz o seguinte. Criei relacionamento 1-1 com as tabelas de PessoaFisica com Cliente, Contatos, Fornecedores. Transformei a classe PessoaFisica em abstract, com uma propriedade PessoaFisica abstract, que é implementada naturalmente por Cliente, Contatos, Fornecedores. Então ao salvar um cliente, automaticamente PessoaFisica é salva e etc.

Atenciosamente

Sidney Lima Filho
Vivina Softhouse
(0xx21) 2222-7330
(0xx21) 7867-2321
55*10*68934

Conheça -------------------------------------------------------------------------------------------------------------------------------------------------------------------------
http://www.vivina.com.br
http://twitter.com/sidneyfilho

2009/12/1 Alexandre Valente <alexandre...@gmail.com>

[Juan Pedro A. Lopes]

Eu entendi o problema errado ou isso é herança relacional? O NHibernate trata isso completamente bem. Só não entendi o porquê das interfaces.

--
Kind regards,
Juan Lopes

juanp...@gmail.com
con...@juanlopes.net
http://juanlopes.net
http://twitter.com/juanplopes

"E se o mundo não corresponde em todos os aspectos a nossos desejos, é culpa da ciência ou dos que querem impor seus desejos ao mundo?" - Carl Sagan

[Daniel Moreira Yokoyama]

A situação é parecida. Mas como eu disse, talvez eu tenha levado o conceito de coesão muito a sério, a ponto de não querer que o meu repositório Cliente manipulasse a tabela PessoaFisica, ou mesmo que instanciasse o repositorio de PessoaFisica para efetuar o Save. Quis deixar tudo isso flexível já que pra esse segmento não existe uma maneira definida comum entre todos os nossos clientes.

Atenciosamente,

Daniel Moreira Yokoyama.
http://halonfullestuse.wordpress.com/

"I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do."
(HAL 9000)

2009/12/1 Sidney Lima Filho <sidney...@vivina.com.br>

[Daniel Moreira Yokoyama]

As interfaces servem para orientar os repositórios... Veja bem, o meu objeto Médico não está ligado diretamente a tabela médicos, mas distribuído em várias tabelas. Para cada tabela eu criei um repositório separado e uma interface que orienta o repositório se o objeto pertence àquela tabela ou não.

 

Assim:

 

public class Physician : IMasterObject, IPhysician, IVisitable

 

public class GeneralRepository

{ public void Save(Object Item)

  { foreach(Repository repository in this.Repositories)

      repository.Save(Item);

  }

}

 

public class MasterObjectsRepository : Repository

{ public void Save(Object Item)

  { if(Item is IMasterObject)

     //Save logic here

  }

}

 

public class VisitablesRepository : Repository

{ public void Save(Object Item)

  { if(Item is IVisitable)

     //Save logic here

  }

}

 

public class PhysiciansRepository : Repository

{ public void Save(Object Item)

  { if(Item is IPhysician)

     //Save logic here

  }

}

 

 

 

Desta forma tudo funciona com coesão. Até mesmo princípios como Single Responsability e Open/Closed. Claro que tem mais coisas no meio, que apanhamos depois pra implementar, que acabou ferindo um pouco essa idéia (como transportar um SqlTransaction entre os repositórios até o processo concluir) e por isso hoje estamos pensando em aprimorar isso pra tirar o lixo que acabou surgindo durante a evolução.

 

 

Atenciosamente,

Daniel Moreira Yokoyama.
http://halonfullestuse.wordpress.com/

"I am putting myself to the fullest possible use, which is all I think that any conscious entity can ever hope to do."
(HAL 9000)

2009/12/1 Juan Pedro A. Lopes <zero...@gmail.com>

[Juan Pedro A. Lopes]

Tudo bem, assim como uma herança relacional normal.

Tal qual: https://www.hibernate.org/hib_docs/nhibernate/html/inheritance.html

[Daniel Moreira Yokoyama]

Parece que chegamos a algo que atenda bem, embora eu não tenha entendido algumas coisas (nunca trabalhei com nHibernate).

 

Estou tentado ler a respeito mas caso alguém já tenha uma resposta na ponta da língua:

 

Os exemplos demonstrados em https://www.hibernate.org/hib_docs/nhibernate/html/inheritance.html mostram o uso de classes que implementam IPayment e faz o mapeamento destas tanto em uma única tabela, como em uma tabela por subclasse como uma tabela por classe concreta... mas se eu não quiser mapear nenhuma classe, e manter somente o mapeamento original de IPayment, o nHibernate aceita? (sinceramente, isso pode estar implícito em algum lugar, mas como nunca testei o nHibernate, estou procurando por algum exemplo explícito).

 

E como anda o suporte do nHibernate para LINQ?