personalizações cliente

Question

Temos um produto com uma base instalada de cerca de 50, mais de 50% destas instalações têm personalizações no código para a lógica de negócios, e que é feito atualmente por grandes declarações if e switch.

Estamos atualmente no processo de atualizar o código para .NET 3.5 e gostaria de lidar com as personalizações de uma forma mais gerenciável. As únicas formas que podemos pensar no momento são: ou vara com as grandes declarações if e switch ou ter arquivos separados dentro controle do código fonte para cada cliente, que por sua vez não parece ser ideal.

Existe uma forma aceitável de lidar com um grande número de personalizações através de uma base de código?

Answer 1

Eu seria tentado a organizar as coisas de modo que a personalização é no texto de forma (possivelmente XML, mas eu acho que não é a única opção), e a aplicação principal é genérica, e recebe o cliente específico apresenta ao analisar esses arquivos de configuração .

Você poderia, então, ter um repositório para cada cliente, arquivos contendo de configuração (e possivelmente recursos, como logotipos e / ou scripts personalizados), e um repositório para a aplicação principal.

Para uma determinada versão do cliente, o sistema de compilação, em seguida, reúne automaticamente a aplicação e repositório do cliente, e constrói a versão personalizada.

Eu tenho experiência com esse sistema um, e você pode obter bastante extensa personalização dessa forma. Isso torna as coisas um pouco mais complexo do lado da aplicação em primeiro lugar, porque você precisa adicionar analisar a funcionalidade, mas faz a gestão de várias versões de clientes muito mais simples, e um pouco menos propenso a erros.

Answer 2

Não é este chamado herança ? Tendo aulas se estendem desde classes de base, adicionando funcionalidade personalizada. Sempre que tenho um grande número de Se do ou dos casos, eu questão de saber se eu deveria refatorar em várias classes.

Answer 3

Um quadro DI em combinação com herança poderia manter o seu sistema de acordo para abrir / princípio fechado, seria torná-lo mais modular, e iria resolver ciclo de vida e distribuição problema, como quando você precisa distribuir uma biblioteca de base que foi prorrogado por um cliente específico.

Por exemplo, você pode ter uma transferência de classe em BaseLibrary e então você pode ter uma classe LoggingTransfer estende Transfer in biblioteca cliente X que contém somente o código que personaliza a funcionalidade base.