UI e relacionamento de aplicação

Question

Eu li muitos artigos sobre a interface do usuário, Buisness Logic, WCF, COI, mas ainda assim, uma coisa está faltando na minha mente. Eu construo um aplicativo Winforms e um aplicativo de console. O aplicativo console é o cérebro. Agora, em toda a arquitetura cliente-servidor, o cliente "sabe" o servidor, envie a solicitação e obtenha a resposta. Meu qestion é o seguinte:

1) Como o aplicativo de console pode exibir uma mensagem para o usuário se ele não conhece a existência da interface do usuário? A interface do usuário deve verificar e pool para as mensagens a cada x mseg? É uma boa abordagem?

2) O que, no caso de os formulários da interface do usuário, devem exibir um preço de ticker, por exemplo, o preço das ações que muda o tempo todo? Deveria solicitar o preço do ticker do aplicativo Console a cada 200mec? ou registrar uma função de retorno de chamada no aplicativo de console para que o aplicativo do console possa chamá -lo? No entanto, ele não transforma a interface do usuário em um servidor agora?

3) O que acontecerá, caso eu queira adicionar recursos de terminal ao meu aplicativo (por exemplo, CLI Telnet), como devo projetá -lo? O servidor Telnet como cliente e meu aplicativo de console como servidor? Existe um design que pode me ajudar a conseguir isso? TÁXI? Perguntei a muitas pessoas e parece que ninguém está usando ... é assim?

Obrigado, Eyal

Answer 1

Seu programa deve ser projetado de forma que você possa substituir uma interface do usuário por outro. O programa deve poder ter a função lógica independentemente da interface que o usuário vê. Dê uma olhada no MVC e Observador padrões.

Uma boa medida do seu programa é através das interfaces que são disponibilizadas para o usuário [chamadas de API, GUI baseada em console, interface baseada em console, interface líquida, web] Não estou implicando que você deve reorientar a intenção do aplicativo de ser Ao torná -lo muito flexível com a interface. Estou sugerindo que sua interface não tenha nada a ver com a lógica e o armazenamento de dados do seu aplicativo.

Ticker de estoque: tenha um padrão de Oberserver que transmite um novo evento a cada 200 mm ou em alterações. A visualização do ticker seria um assinante desses eventos.

Answer 2

Por que você não cria o "cérebro" como uma biblioteca? Tanto uma interface WinForms quanto um aplicativo de console são interfaces de usuário e devem ser separados da lógica. Isso permite acesso mais fácil às funções e você também pode se inscrever nos eventos.

Answer 3

Você deve evitar a arquitetura que está pensando. É complicado obter dois processos separados para trabalhar juntos. O sistema operacional coloca uma grande parede entre os processos para garantir que um processo de comportamento mal não possa desestabilizar outro. Cada um dos processos tem sua própria visão da memória, o Windows (e o .NET especialmente) dificulta o compartilhamento da memória para os processos.

Você teria que estabelecer um canal de comunicação entre os processos para fazê -los trabalhar juntos. Um tubo ou um soquete é a escolha usual, o modelo mental aqui é de máquinas conversando entre si sobre uma rede. Isso pode ser muito estranho, você teria todas as desvantagens de um aplicativo da Web, nenhuma das vantagens de um aplicativo WinForms Client ou Console Mode. Também não é muito confiável, é difícil falha de um processo diagnosticar, relatar e recuperar pelo outro aplicativo. Tenho certeza de que você viu o que pode dar errado ao usar seu navegador da Internet.

Você pode obter o que deseja de um aplicativo. A classe System.Threading.Thread oferece o equivalente moral do seu aplicativo de modo de console. Fazer a interface do usuário exibir mensagens do encadeamento do cérebro é bastante simples com a classe BackgroundWorker ou o método Control.Begin/Invoke (). Apenas "razoavelmente", acertar a interopidade do thread ainda é um esforço.

Existem duas maneiras de implementar a atualização do ticker de ações. O push vs a abordagem de atração. A abordagem de push é deixar o encadeamento de segundo plano notificar ativamente o encadeamento da interface do usuário de que uma atualização está disponível. BackgroundWorker.ReportProgress ou Control.Begin/Invoke para fazer isso. Com 200 ms ms atualizando, isso não é um problema.

Em tarifas como essa, o modelo de tração também funcionará. Você usaria um cronômetro na interface do usuário para obter um método para ser executado periodicamente. Ele poderia ler o valor de uma propriedade compartilhada no método de tick do timer. Você precisará usar a instrução BLOCK no encadeamento de segundo plano e no método de carrapato para garantir que o valor não possa alterar exatamente como o thread da interface do usuário está lendo o valor.

Você deve favorecer o modelo de tração quando o valor puder mudar muito rapidamente, pressionando a uma taxa que trará o thread da interface do usuário de joelhos quando o tempo necessário para atualizar a interface do usuário for maior que o período entre as atualizações do thread em segundo plano. O tópico da interface do usuário ficará para trás e não fica de acordo com seus deveres normais. Uma interface do usuário congelada é o diagnóstico, OOM é o resultado final. 200 ms não devem ser um problema, a menos que você fique muito chique ou desleixado com suas atualizações da interface do usuário, o Push deve funcionar.

Terei que me juntar à Liga dos Amigos que você consultou sobre os servidores Telnet. Não tenho certeza de que problema eles resolvem, eles são o equivalente de 1990 a um servidor da Web quando todos estavam usando um terminal de tela verde para conversar com um computador. Talvez se aplique à necessidade de conectar um aplicativo de modo de console separado a um aplicativo de interface do usuário. Você não usaria o Telnet para fazer isso, um soquete é um canal genérico. .NET remoto ou, melhor, o WCF é a camada que fica no topo desse canal para evitar ter que lidar com as complicações de espremer dados ou parâmetros de método através de um tubo de bytes. Perfira isso se você já estiver completamente encaixotado em uma solução de vários processos. Você não deve ser para um aplicativo de ticker de estoque, ninguém se importa de que maneira eles marquem se não houver ninguém lá para olhá -los. Tree caindo na floresta, talvez.