Re: [reverbel-sod] [EP1] Manipular estado do Customer

["Rafael de F. Ferreira" <rafael@xxxxxxxxxxxxxxxxxx>]

Não discordo que esta solução resolve o problema, e sem maiores
consequências no nosso caso. Mas antes eu disse que não gostava muito
dela porque, do ponto de vista de orientação à objetos, acho que não é
o melhor procedimento. O que poderia ser uma interação direta entre
dois objetos do domínio acaba sendo intermediada por um repositório de
dados externo e isso torna difícil implementar e manter regras de
negócio mais complicadas que as do EP. Um exemplo é se existisse um
requerimento para impedir que os Customers alugassem filmes se tiverem
algum empréstimo atrasado. Esse tipo de lógica se encaixaria
naturalmente no objeto customer, mas como ele não fica sabendo da
transação de aluguel, teríamos que encontrar algum outro lugar mais
artificial para implementar esse código.

Essa questão se relaciona com o problema todo de Entidades vs.
Serviços. Se uma chamada remota (como à rentTo) desencadear uma
cascata de outras chamadas remotas síncronas então a performace é
bastante prejudicada. Além disso, percebemos a dificuldade envolvida
em alterar uma interface remota publicada para interoperação entre
grupos diversos. O Ted Neward falou sobre isso numa entrevista
recente: "Once you publish an interface like that, you can never
change it because getting all of those players to agree on a change is
just flat out impossible. You lose health, sanity and hair when you do
this." (http://tinyurl.com/kpxgv). Uma service façade bem definida
(talvez com pontos de extensão) na frente de um modelo de domíno
não-remoto deixa o modelo mais flexível para evolução e evita a queda
de performance com da cascata de invocações remotas.

My 2 cents.
Rafael de F. Ferreira.

On 4/13/06, Francisco Reverbel <reverbel@xxxxxxxxxx> wrote:
> On Sun, 2006-04-09 at 22:46 -0300, Rafael de F. Ferreira wrote:
> > Estou com uma dúvida a respeito de como registrar o alguel de um
> > exemplar para as entidades Customer.
> >
> > Na IDL do Customer não consta nenhuma operação para manipular a
> > MovieCopyList dos exemplares alugados. Como a operação rentTo(...) da
> > interface MovieCopy recebe uma referência remota para um Customer,
> > também não posso fazer um downcast para o tipo do servant do customer.
> > Sem contar que não é boa prática ficar fazendo casts o tempo todo.
> >
> > Eu pensei em dois workarounds, mas nenhum parece muito legal. Uma
> > alternativa seria fazer o servant do Customer buscar em algum lugar
> > conhecido a lista de MovieCopy's alugadas para ele no momento em que
> > precisasse.
>
> Essa solução não é ruim. Faça o servente da MovieCopy ter um campo com o
> id do Customer para o qual a MovieCopy foi alugada. (Pense em como se
> implementa um relacionamento 1 para N num BD relacional: colocando na
> tabela correspondente à entidade que aparece com cardinalidade N uma
> coluna com a chave estrangeira da tabela correspondente à entidade que
> aparece com cardinalidade 1 no relacionamento.)
>
> Para construir a lista de MovieCopies alugados para um Customer,
> percorra a coleção de serventes de MovieCopy e olhe o campo "id do
> Customer" de cada servente. (No caso de entidades armazenadas num BD
> relacional, você faria isso com um comando SQL: "SELECT ID FROM
> MOVIE_COPY MC WHERE MC.CUSTOMER_ID = CUSTOMER_ID".) Note que a coleção
> de serventes de MovieCopy servirá também para implementar a interface
> MovieCopyHome.
>
> Repare que basta obter o id (chave) de cada MovieCopy. Tendo esses ids,
> você pode convertê-los em referências CORBA para objetos MovieCopy
> chamando poa.id_to_reference() (caso você use um POA com a política
> RETAIN e deixe todos os objetos MovieCopy ativos o tempo todo) ou
> poa.create_reference_with_id() (se os objetos MovieCopy não ficarem
> ativos o tempo todo -- este vai ser o caso no EP2).
>
> Você também pode fazer conversão de id em referência CORBA para
> implementar o método getTaker() no servente da MovieCopy. Tendo o campo
> "id do Customer" nesse servente, basta converter o id em referência
> CORBA para um Customer.
>
> Em vez de ter, no servente da MovieCopy, um campo com o id desse
> Customer que alugou a MovieCopy, uma outra alternativa é ter, nesse
> servente, um campo com uma referência CORBA para o Customer que alugou a
> MovieCopy.
>
> > Outra maneira seria implementar o método
> > MovieCopy.rentTo(...) de modo a buscar uma referência local para o
> > servant concreto do Customer no servidor através do ID dele e chamar
> > uma operação como CustomerImpl.rent(MovieCopy).
>
> Só agora entendi que você está querendo estabelecer links na outra
> direção (de Customer para uma coleção de MovieCopies). Isso é
> desnecessário, basta o link de MovieCopy para Customer.
>
> Reverbel
>
> > Alguém tem alguma sugestão?
> >
> > Obrigado;
> > --
> > Rafael de F. Ferreira.
> >
>
>


--
Rafael de F. Ferreira.