Silverlight, assíncrona, o carregamento lento, qual é a melhor maneira?

votos
0

Comecei a usar o Silverlight / flex e imediatamente colidiu com o chamado serviço assíncrono. Estou acostumado a resolver os problemas de acesso a dados em um OO vias com um servidor buscar mecanismo ou outro.

Eu tenho o seguinte exemplo de código trivial:

public double ComputeOrderTotal(Order order) 
{ 
   double total = 0;
   // OrderLines are lazy loaded
   foreach (Orderline line in order.Orderlines) 
   { 
       // Article,customer are lazy loaded 
       total = total + line.Article.Price - order.Customer.discount;
   }
   return total;
}

Se bem entendi, este código é impossível em Flex / Silverlight. As forças de carregamento lento você para trabalhar com chamadas de retorno. IMO o expample simples acima vai ser uma bagunça BIG.

Alguém pode me dar uma forma estruturada para implementar o acima?

Editar:

  • O problema é o mesmo para Flex / Silverlight, código pseudo faria muito bem
  • Não é realmente ORM relacionados, mas a maioria ORMs usar o carregamento lento então eu vou remover essa tag
  • O problema é o carregamento lento no modelo
  • O exemplo acima seria muito factível de todos os dados foi na memória, mas assumimos alguns tem de ser obtido a partir do servidor
  • Closueres não ajuda, pois algumas vezes os dados já está carregado e nenhuma obtenção assíncrona é necessária
Publicado 10/12/2008 em 09:23
fonte usuário
Em outras línguas...                            


7 respostas

votos
1

Flex tem um modelo de segmento único. Se você fizer uma chamada síncrona para o servidor web, você bloquear todo o GUI da aplicação. O usuário teria um aplicativo congelado até que a chamada termina (ou vezes em uma condição de erro de rede, etc.).

Claro programas RIA reais não são escritas dessa forma. Sua GUI permanece acessível e ágil para o usuário através da utilização de chamadas assíncronas. Ele também torna possível ter indicadores de progresso reais que oferecem cancelar botões e tal, se a natureza dos mandados de interação tal.

Antigo, Má experiência do usuário da web 1.0 aplicações exibiu o comportamento síncrono em suas interações com a camada web.

Como meu artigo ligado assinala, o modelo single-threaded assíncrona juntamente com ActionScript3 fechamento é uma coisa boa porque é um modelo de programação muito mais simples do que a alternativa - a criação de aplicativos multi-thread. Multi-threading foi a abordagem de escrever Java Swing cliente-servidor ou aplicações C # .NET WinForm, a fim de alcançar, uma experiência semelhante responsivo fluido-em-todos-times usuário na GUI.

Aqui está outro artigo que investiga este assunto inteiro de assíncrona, arquitetura aplicativo distribuído de mensagens / event-driven:

Edifício eficaz Empresa Sistemas de Software Distribuído comunicação baseada em dados vs comunicação orientada para o comportamento

Respondeu 23/12/2008 em 06:42
fonte usuário

votos
1

Na minha experiência direta com Flex, eu acho que essa discussão está ficando muito complicado.

Sua visão OO conceitual não é diferente entre a sincronização e asynch. A única diferença é que você usa manipuladores de eventos para lidar com a conversa host na DAL, em vez de algo voltar de uma chamada de método. E que muitas vezes acontece inteiramente no lado do host, e não tem nada a ver com Flex ou Silverlight. (Se você estiver usando AIR para um aplicativo de estação de trabalho, então pode ser no código do cliente, mas o mesmo se aplica. Como bem se você estiver usando AJAX prolongada. Silverlight, é claro, não tem ar equivalente.)

Eu tenho sido capaz de projetar tudo o que preciso, sem quaisquer outras alterações necessárias para acomodar asynch.

Respondeu 23/12/2008 em 03:55
fonte usuário

votos
1

Eu não posso falar para o Silverlight, mas Flex é uma tecnologia de cliente do navegador web e não tem qualquer driver de banco de dados embutido no tempo de execução do Flash. Você pode fazer interações de protocolo HTTP para um servidor web em seu lugar. É lá no servidor web de camada intermediária onde você vai fazer qualquer ORM no que diz respeito a uma conexão de banco de dados, tais como Java JDBC. Hibernate ORM e iBATIS são duas escolhas populares no espaço de camada intermediária Java.

Além disso, por causa disso:

Falácias da computação distribuída

Você não faz interações síncronas de um cliente Flex aos seus serviços de camada intermediária. operações de rede síncronas tornaram-se verboten estes dias e são a assinatura marca de um aplicativo mal projetado - como devido a razões enumeradas no link acima, o aplicativo pode (e muitas vezes) apresentam uma experiência de usuário muito ruim.

Você sim fazer assíncrono chamadas para recuperar dados, carregar os dados no modelo de objeto do aplicativo cliente (s), e proceder à execução de operações no modelo. Com o Flex e BlazeDS você também pode ter os dados de pressão de camada intermediária para o cliente e atualizar o modelo do cliente objetos de forma assíncrona. (Ligação de dados é uma forma de responder aos dados que está sendo atualizado de forma orientada evento.)

Tudo isso provavelmente parece muito distantes da natureza da investigação em sua postagem -, mas sua postagem indica que você está fora em uma base inteiramente incorreta quanto à forma de compreender as tecnologias do lado do cliente que têm programação assíncrona e event-driven cozido em sua fundamentais arquitetura. Estas tecnologias de cliente RIA são concebidos desta forma completamente de propósito. Então você vai precisar para aprender seu modo de pensar se você quer ter uma experiência boa e produtiva usá-los.

Eu vou para isso com mais detalhes e com uma perspectiva Flex, neste artigo:

Flex Async I / O vs Java e C # Enfiar explícita

Respondeu 23/12/2008 em 03:47
fonte usuário

votos
1

Sim devo concordar que o mapeamento O / R geralmente é feito no lado do servidor de sua aplicação. Em SilverLight maneira assíncrona de execução é o padrão desejado para usar quando se trabalha com serviços. Por que os serviços? Porque como disse antes não há nenhuma ferramenta de mapeamento O / R no momento em que pode ser utilizado no lado do cliente (SilverLight). A melhor abordagem é ter o seu O / R mapeados dados expostos por um serviço que pode ser consumida por um aplicativo do Silverlight. A melhor forma no momento é usar DataServices ADO.NET para transportar os dados, e no lado do cliente para gerenciar os dados usando LINQ to Services. O que é realmente interessante sobre ADS (antigo Projeto Astoria) é que ele é projetado para ser usado com o Entity Framework, mas a boa gente também implementou suporte para IQueriable então basicamente você pode ligar qualquer provedor de dados que suportam LINQ.OpenAccess , LLBLGen, etc. Para enviar as atualizações de volta para o servidor de fonte de dados é necessário para suportar o ADS IUpdateable.

Você pode olhar exatamente como isso poderia ser feito em uma série de blogposts que tenho preparado aqui: Introdução ao ADO.NET Data Services e Telerik Open Access

Respondeu 19/12/2008 em 09:05
fonte usuário

votos
0

C # 5 async / esperam construir quase exatamente o que eu quero ..

assistir a apresentação por Anders Hejlsberg

Respondeu 12/11/2010 em 13:04
fonte usuário

votos
0

Falando sobre o Silverlight, você deve definitivamente verificar serviços de RIA .

Simplesmente, ele traz o DataContext do servidor para o cliente de onde se pode de forma assíncrona consultá-lo (não há necessidade de escrever serviços WCF à mão, tudo é feito por RIA).

Respondeu 21/12/2009 em 17:23
fonte usuário

votos
0

Silverlight é uma tecnologia de cliente eo Object - mapeamento relacional acontece completamente no servidor. Então você tem que se esqueceu do ORM no Silverlight.

Seguindo seu exemplo, o que você tem a fazer é criar um webservice (SOAP, RESTO ...) que pode dar o seu cliente Silverlight o objeto completa "Ordem". Depois de ter o objeto que você pode trabalhar com ele sem comunicação com o servidor em um normal - forma síncrona.

Respondeu 12/12/2008 em 12:07
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more