Reutilização baseada em servidor - DLL, GAC ou REST?

Question

Temos uma peça de funcionalidade usada por vários aplicativos diferentes (clientes) no mesmo servidor. Ele pode ser melhor modelado como um serviço, possui um banco de dados de back -end e haverá apenas uma versão da funcionalidade e o banco de dados em uso a qualquer momento.

Até agora, empregamos a reuse simples da DLL, com a funcionalidade, seu arquivo de configuração e dependências implantadas em todos os lugares em que é usado. Como as alterações agora precisam ser feitas em vários lugares, esse método é doloroso ao criar novas versões da funcionalidade ou quando novos clientes desejam usá -lo.

Estamos nos perguntando se existe uma maneira melhor de fazer isso e apresentamos duas alternativas possíveis.

1. Coloque a DLL (e as dependências) no GAC. A questão é então como configurar o componente. Como os clientes não têm interesse na configuração, estamos inclinados para armazenar o arquivo de configuração em um caminho codificado no servidor.

2. Publique a funcionalidade como um serviço interno (baseado em REST). O acesso a ele pode ser limitado a clientes internos usando o firewall.

Como o vemos, os profissionais do número 1 parecem ser desempenho e possivelmente segurança, enquanto o número 2 pode ser visto como mais simples de configurar.

Estamos perdendo algo importante aqui? Alguém já esteve em uma situação semelhante antes e quer compartilhar algumas dicas?

Answer 1

Este é um problema com o qual lutei muitas vezes e realmente não há nenhuma melhor resposta, além, depende. Minha opinião pessoal é que você precisa ficar longe da opção 1 por alguns motivos:

1. Ao fazer com que todos os seus clientes compartilhem um único binário, agora exigirá que todos os seus clientes sejam testados cada vez que você fizer uma alteração. Agora eu sei que, no seu caso exato, você pode fazer isso de qualquer maneira, pois podemos assumir que você estaria modificando o banco de dados que fica atrás do componente.
2. Não codifique nada. Você pode armazenar seu caminho de configuração em uma seção AppSettings no arquivo Machine.Config.

Quanto à opção 2, uma alternativa seria usar o WCF (assumindo que seu ambiente possa apoiá -lo). Usando o WCF, você pode usar um transporte TCP usando serilização binária (e pode haver um transporte de memória compartilhado). Ambos ajudariam a aproximar a diferença de desempenho (embora a opção 1 sempre supere uma abordagem baseada em serviço).

Ao ir com a opção 2, você também alivia a necessidade de testar todos os clientes, pois pode desenvolver testes automatizados para validar que seu contrato não está quebrado. Isso permitirá que você publique em um único local, execute testes automatizados rápidos e saiba que você não está quebrando os clientes.

Com isso dito, você pode realizar a mesma coisa usando a opção 1 e um bom conjunto de testes de unidade, mas com base na minha experiência de experiência 2 será mais fácil a longo prazo.

A opção 2 também permite ampliar o serviço no futuro, se precisar de mais energia da CPU.

Pessoalmente, acho que a opção 1 é mais fácil de configurar, pois você não terá que lidar com a configuração do seu firewall, lidando com a autenticação, configurando um serviço etc ... Também será mais fácil depurar (a distribuição de um aplicativo apresenta novos tipos de falhas Por exemplo, o site que hospeda seus falhas de serviço e seus clientes começam a obter falhas).

Uma última sugestão é que você use um padrão de proxy / fachada para insolar seus clientes a partir da localização real do serviço. Isso permitirá que você se expanda com o tempo sem precisar modificar o código do cliente.

Answer 2

Como Josh já disse, infelizmente a resposta para esse tipo de pergunta é frequentemente "depende".

Sou um grande fã do GAC, mas você só deve colocar o código do qual você tem certeza de que funciona (quase) perfeitamente e não precisa ser atualizado com muita frequência. Enquanto uma parte do código estiver "em desenvolvimento", basta publicá -lo junto com todos os aplicativos que o utilizam.

Answer 3

Eu diria que o uso da opção 1 seria mais simples e fácil, especialmente porque você só precisará gastar tempo extra limitando a disponibilidade do resto. (trocadilho intencional!)

Answer 4

Josh aponta o WCF como uma opção, e é assim que eu iria com isso.

Esse problema é exatamente o que a SOA deve resolver!