Criando uma biblioteca compartilhada que pode ser usada com aplicativos da área de trabalho e projetos da web


7

Eu estive envolvido em vários projetos de desktop MVC.NET e c # em nossa empresa durante o último ano ou mais, enquanto também conseguia manter meu nariz enfiado em outros projetos (é claro que é uma capacidade de aprendizado somente leitura).

A partir disso, notei que, nos vários projetos e equipes, há muitas funcionalidades que foram bem projetadas contra boas interfaces e abstrações. Como tendemos a gostar de nosso próprio trabalho às vezes, notei que alguns projetos tinham exatamente a mesma classe, método copiado para ele, pois obviamente funcionava em um e, portanto, era facilmente movido para um novo projeto (provavelmente pelo mesmo desenvolvedor que escreveu originalmente)

Mencionei esse fato em uma de nossas reuniões de programadores que ocasionalmente realizamos e sugeri que inseríssemos algumas dessas funcionalidades em uma biblioteca principal da empresa que possamos construir com o tempo e usar em vários projetos. Todos concordaram e eu comecei a investigar essa possibilidade.

No entanto, me deparei com uma pedra de tropeço bem cedo. Nossa equipe se concentra principalmente no MVC no momento e temos projetos principalmente no 2.0, mas estamos começando a ramificar para o 3.0. Também temos vários aplicativos de área de trabalho que podem se beneficiar de algumas classes compartilhadas e métodos auxiliares básicos.

Inicialmente, ao criar essa DLL, incluí algumas classes compartilhadas que poderiam ser usadas em qualquer tipo de projeto (Web, Cliente etc.), mas comecei a procurar adicionar alguns módulos compartilhados que seriam úteis apenas em nossos aplicativos MVC. No entanto, isso significava que eu tinha que incluir uma referência a algumas DLLs da Web da Microsoft para aproveitar algumas das classes que eu estava criando (neste estágio MVC 2.0).

Agora, meu problema é que temos uma DLL compartilhada que tem referências a bibliotecas específicas da Web que também podem ser usadas em um aplicativo cliente. Além disso, nossa DLL referenciou inicialmente o MVC 2.0 e, eventualmente, passaremos para o MVC 3.0 para todos os projetos. Mas muitas das classes nesta biblioteca ainda espero que sejam relevantes para o MVC 3 etc.

Nosso código nessa DLL é separado em seus próprios namespaces, como:

  • CompanyDLL.Primitives
  • CompanyDLL.Web.Mvc
  • CompanyDLL.Helpers etc etc

Então, minhas perguntas são:

  1. Não há problema em criar uma biblioteca compartilhada como essa ou, se tivermos recursos específicos da Web, devemos criar uma DLL da Web separada, direcionada apenas a uma estrutura específica ou versão do MVC?
  2. Se estiver tudo bem, que tipo de problemas podemos enfrentar ao usar a biblioteca que faz referência ao MVC 2 em um projeto MVC 3, por exemplo. Eu estaria pensando que podemos encontrar algum tipo de problema de compatibilidade, ou mesmo problemas em que os desenvolvedores que usam a biblioteca não percebem que precisam das bibliotecas MVC 2.0. Eles podem querer usar apenas algumas das classes genéricas, etc.

O conceito parecia uma boa ideia na época, mas estou começando a pensar que talvez não seja realmente uma solução prática. Mas o número de vezes que eu vi classes e métodos copiados em projetos porque eles são comprovados código testado é um pouco irritante para ser perfeitamente honesto!

ATUALIZADO : Além da resposta de Bernards, que aceitei e parece ser um bom conselho. No entanto, quero criar algumas classes compartilhadas que provavelmente serão úteis nos projetos MVC 2 e MVC 3. No entanto, meu assembly compartilhado terá que fazer referência a uma das estruturas do MVC para que eu possa criar minhas classes compartilhadas em primeiro lugar.

Tão mais para expandir no meu Q2 acima.

  1. Se eu quisesse uma solução da Web MVC 3, teria que ter um projeto CompanyDLL.Web.Mvc3 compartilhado que, em seguida, faria referência específica ao MVC 3? Isso significaria copiar todo o código da minha solução CompanyDLL.Web.Mvc2 para este novo projeto compartilhado do Mvc3?

Parece que estou perdendo algumas habilidades fundamentais de design na criação de montagens compartilhadas e na construção e referência em diferentes versões de estrutura. Ou pode ser tão simples quanto sugá-lo e criar bibliotecas CompanyDLL.Web.Mvc2 , CompanyDLL.Web.Mvc3 , CompanyDLL.Web.Mvc4 etc etc ...

Respostas:


5

Crie bibliotecas compartilhadas separadas para suas diferentes plataformas (desktop e web). Tudo o que essas duas bibliotecas precisarão deve ser uma biblioteca compartilhada separada. Assim, você pode dividir essas bibliotecas da seguinte maneira:

  • Company.Core: Usado por todas as bibliotecas. Contém código genérico, classes auxiliares etc. que não são específicas de nenhuma plataforma. Não faz referência a outras bibliotecas compartilhadas.
  • Company.Core.Desktop: Usado por aplicativos de desktop. Company.CoreBiblioteca de referências .
  • Company.Core.Web: Usado por aplicativos da web. Company.CoreBiblioteca de referências .

Isso permite alterar a tecnologia da Web que está sendo usada sem afetar a tecnologia de desktop que está sendo usada. Isso também permite que você adicione mais plataformas no futuro (por exemplo Company.Core.Mobile).

Verifique se essas bibliotecas são testadas em unidade e nunca mais copiem o código entre os projetos.


Obrigado Bernard pelo conselho. E quanto a problemas com a referência a diferentes versões das bibliotecas da Microsoft nas DLLs compartilhadas?
Dreza 26/03/12

Você quer dizer versões diferentes das mesmas bibliotecas? MVC 2 vs. MVC 3?
Bernard

Sim, foi exatamente isso que fizemos na mesma circunstância. Perfeito.
gahooa

@Bernard. Sim. Eu esperaria que a nossa biblioteca compartilhada fizesse referência ao MVC 2. Mas e se um novo projeto que usa essa biblioteca quiser usar o MVC 3. Não tenho certeza se isso é um problema, mas algo que não conheço os efeitos
dreza

2
+1; Eu teria certeza de que, a menos que você esteja usando MUITO recursos específicos das versões do MVC, eles são projetados para serem compatíveis com a maior parte do tempo.
precisa saber é o seguinte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.