Boas práticas em soluções do Visual Studio [fechado]

10

Espero que seja uma pergunta simples de relatividade. Estou começando a trabalhar em um novo projeto interno para criar a rastreabilidade de dispositivos reparados dentro dos edifícios.

O banco de dados é armazenado remotamente em um servidor da web e será acessado via API da web (saída JSON) e protegido com OAuth. A GUI do front end está sendo feita no WPF e o código comercial em C #.

A partir disso, vejo as diferentes camadas Apresentação / Aplicativo / Armazenamento de dados. Haverá código para gerenciar todas as chamadas autenticadas para a API, classe para representar entidades (objetos de negócios), classes para construir as entidades (objetos de negócios), partes da GUI do WPF, partes dos modelos de exibição do WPF e assim por diante.

É melhor criar isso em um único projeto ou dividi-los em projetos individuais?

No meu coração, digo que deve haver vários projetos. Eu fiz isso nos dois sentidos anteriormente e achei o teste mais fácil com uma única solução de projeto, no entanto, com vários projetos, podem surgir dependências recursivas. Especialmente quando as classes têm interfaces para facilitar o teste, descobri que as coisas podem se tornar estranhas.

project-management visual-studio JonWillis
fonte
11
Eu os separaria no que faz sentido para o projeto.
Ramhound 6/10/11
Alguém mais tem alguma idéia, uma sobre o projeto para manter as interfaces, como sugeriu MattDavey. Eu usei essa abordagem antes para evitar as dependências mencionadas. Ou as interfaces da classe x devem estar no mesmo projeto da classe x.
91111 JonWillis
Além disso, quais camadas você usa. Eu vi algumas variedades diferentes, embora as principais sejam Apresentação / Aplicativo / Infraestrutura. Alguns também dividem o aplicativo em 2 partes, aplicativo + serviço. Alguns modelos também mencionam uma camada específica para lógica de negócios, que para mim pode ser incluída nos próprios objetos de negócios.
9118 JonWillis

Respostas:

8

Depende do tamanho do projeto

Aqui estão as diretrizes que costumo usar

  • Um projeto pequeno, com um punhado de páginas ou menos, eu quase sempre mantenho um único projeto.

  • Se a camada de acesso a dados do projeto pequeno for grande ou complexa, eu poderia separá-la em sua própria camada, mas, caso contrário, ela ficará em sua própria pasta.

  • Se o projeto for maior, quase sempre terei um projeto separado para o DAL, e qualquer divisão adicional dependerá de onde estão os limites entre a funcionalidade do aplicativo.

  • Se o aplicativo tiver várias finalidades, cada uma com suas próprias visualizações, modelos de visualização etc., geralmente separarei cada peça em sua própria área. Se cada seção for pequena, eu as separo por uma pasta. Se cada seção for grande, eu as separarei por um projeto.

  • Se eu tenho vários projetos que precisam referenciar o mesmo conjunto de objetos ( ViewModelBase, RelayCommand, etc), eu vou criar um projeto apenas para os objetos infra-estrutura compartilhada.

  • Se eu tiver uma grande quantidade de estilos / modelos / recursos personalizados compartilhados, criarei um projeto apenas para eles.

Como observação lateral, cometi um erro no meu primeiro grande projeto WPF e os separei colocando Modelos em um projeto, Visualizações em outro e ViewModels em um terceiro. Posso dizer agora que não é o caminho a seguir, pois a manutenção se torna um pesadelo :)

Rachel
fonte
Curioso, que problemas de manutenção você teve ao separar as camadas?
Ian
@ Rachel, eu vou usar o WPF. Então, estaria interessado em saber como você organizou o projeto no final. Eu acho que me lembro de um pequeno projeto MVC que foi difícil ao separar 3 partes em 3 dlls. Para o WPF, Minha visão será a GUI, a entidade / objeto de negócios a ser alterado e o ViewModel a interação entre eles. O ViewModel lidaria com a lógica de chamar um repositório para carregar / salvar os reparos (que, por sua vez, possuem fábricas / APIs da web, etc).
9118 JonWillis
11
@Ian O maior problema foi que a maioria das pequenas alterações, como adicionar um único campo, exigiu que eu buscasse o Model, View, ViewModel e DAL em 4 bibliotecas separadas. O projeto que eu estava trabalhando na época era bastante grande e perdi mais tempo do que gostaria de procurar por arquivos específicos. Desde então, tenho mudado para manter objetos relacionados juntos, por isso, por exemplo, nada Search-relacionados, tais como SearchView, SearchViewModele SearchResultModeltodos seriam agrupados em uma pasta e eu achei torna o aplicativo mais fácil de manter.
Rachel
@Ian Eu também lembro de ter problemas de dependência e funcionando em referências circulares, porque, apesar de meus melhores esforços algumas camadas necessárias para outros de referência, mas que a camada foi referenciá-los, então eu tive algumas soluções feias até que eu reformulado
Rachel
11
@ JonWillis A maioria dos meus projetos WPF é dividida com base nos pontos especificados na minha resposta. Normalmente, o DAL é sua própria camada e cada módulo ou seção do projeto é agrupado (em sua própria pasta, espaço para nome ou projeto, dependendo do tamanho do projeto). Por exemplo, todos os objetos de pesquisa estariam juntos, incluindo a Interfacecamada de dados, mas a camada de acesso a dados real da pesquisa estaria na biblioteca DAL. Muitas vezes eu tenho uma Infrastructureou Commonbiblioteca que contém as classes base comum, interfaces e classes auxiliares.
Rachel
14

Vi os melhores resultados com um projeto por camada, além de um projeto de teste por camada. Vi poucas aplicações que não podem ser realizadas em 10 ou menos projetos na solução, onde a solução abrange tudo .

Não caia na armadilha de usar projetos onde você realmente deseja namespacing. Toneladas de projetos adicionam nada além de sobrecarga para nenhum ganho.

Bryan Boettcher
fonte
9

IMHO separado é quase sempre melhor. Eu quase sempre separo minha camada de dados, a menos que o projeto seja 100% trivial. O motivo é que a camada de dados tende a ser passada com mais frequência. Raramente você conectará uma GUI a várias camadas de dados e espera que funcione bem. O cenário muito mais comum é que você possui uma única camada de dados e deseja que ela seja distribuída por várias GUIs (ASP.Net, WPF e um aplicativo Silverlight, por exemplo). É incrível quando você pode criar o projeto da camada de dados e colocar essa dll como referência na próxima GUI que você criar.

Morgan Herlocker
fonte
+1 Quando estou iniciando novos projetos, muitas vezes construo uma camada de dados simulada que mantém os dados na memória. Permite que eu continue desenvolvendo o restante do aplicativo primeiro. Então eu posso trocá-lo por uma camada de acesso "real" de dados mais tarde ..
MattDavey
Você consideraria entidades (DTO), fábricas e classes usadas para se comunicar com o servidor da Web como parte da camada de dados?
9116 JonWillis
@ JonWillis - Não, provavelmente nem todos. Eu colocaria as fábricas e as classes do servidor da web em um espaço para nome de um projeto de biblioteca de classes. Minha camada de dados típica contém apenas os arquivos dbml e / ou arquivos edmx necessários. Como regra, no entanto, dou às coisas da "biblioteca / estrutura" seu próprio projeto. Definitivamente, eles não precisam ser incluídos no projeto GUI, embora eu veja as pessoas fazendo isso o tempo todo.
Morgan Herlocker
Realisticamente, porém, quanto tempo você levaria para pegar alguns namespaces e ramificá-los em um novo projeto. Eu sinto que é um trabalho de refatoração bastante fácil.
Didier A.
4

Para mim, 4 * é o número mágico. Um projeto para cada camada e um projeto que define todas as interfaces / DTOs necessárias para a comunicação entre elas.

* 7 se você contar testes unitários

MattDavey
fonte
2

Eu sempre usei uma solução única se estou trabalhando nessas camadas diferentes ou se há um acoplamento rígido com elas. Quero pressionar F5 e ter todos os projetos reconstruídos, se necessário. Eu não acho que exista uma maneira "certa" de fazê-lo.

Jeremy
fonte
2

Seu gosto pessoal, a coisa mais importante é ser consistente . Pessoalmente, tenho um projeto separado para cada camada do aplicativo, portanto a separação é óbvia.

Tom Squires
fonte
Quais camadas você separa? Você tem camadas de aplicativos / serviços separadas e, em caso afirmativo, como elas realmente diferem. Sua lógica de negócios está contida no aplicativo / serviço ou são métodos nos objetos de negócios reais?
91111 JonWillis
1

O aumento no número de projetos tem a ver com a habilitação do teste de unidade e a simplificação do gráfico de dependência, a ponto de as coisas não serem tão complexas que as mudanças em uma parte do aplicativo quebram coisas em partes aparentemente não relacionadas do aplicativo.

Funciona quando estou fazendo algum tipo de inversão de dependência, para colocar todos os "contratos", interfaces, classes abstratas, objetos de transferência de dados em um assembly. Em outra montagem, coloquei qualquer coisa que fale com o banco de dados. Os testes de unidade têm sua própria montagem. Se a interface do usuário for fundamentalmente não testável (por exemplo, winforms do ASP.NET), há um benefício significativo em dividir a interface do usuário em código testável e código não testável - um assembly cada. Às vezes, começa a aparecer um código que não tem nada a ver com o banco de dados, a interface do usuário ou qualquer coisa que eu mencionei até agora - é o código que eu meio que desejava estar no framework .NET. Esse código colocarei em um assembly de utilitários ou, pelo menos, o colocarei em qualquer que seja o assembly raiz (provavelmente aquele com as interfaces.

Se todas as montagens fizerem referência a todas as montagens, ou quase isso, elas deverão ser mescladas novamente em uma única montagem. Se você ou as pessoas da sua equipe não tiverem a disciplina necessária para não colocar o código da camada de dados na interface do usuário e a interface do usuário na camada de dados, simplifique as coisas mesclando tudo de volta em uma única camada.

Algumas edições do Visual Studio apresentam problemas de desempenho em cerca de 15 montagens, às vezes depende de que tipo de projeto existe. Às vezes, o descarregamento estratégico dos arquivos do projeto pode ajudar.

MatthewMartin
fonte
Sou o único desenvolvedor da empresa, no momento. E também recém-saído da universidade, tentando incutir boas práticas nos projetos maiores o mais rápido possível. Estou interessado em torná-lo sustentável, porque a especificação do sistema mudou muito antes de eu começar a documentá-lo, contra as solicitações de querer o sistema o mais rápido possível. Na sua opinião, uma montagem que contenha apenas interfaces seria uma solução adequada? Dessa forma, a dependência deve estar apenas nas interfaces e nas classes de fábrica.
91111 JonWillis
11
Sim. É melhor entender a motivação da divisão de montagem, mas se você (ou os membros de sua equipe) não a entender, ainda é uma manobra barata. Portanto, mesmo que você acabe com todas as montagens dependentes de todas as montagens e sem nenhuma esperança de testar a unidade, mover coisas que se comportam como contratos (interfaces, classes abstratas) para sua própria montagem é um passo na direção certa e tem poucas desvantagens.
MatthewMartin
-2

A única boa razão para ter mais de um projeto é se você precisa compartilhar um conjunto de classes e arquivos em vários aplicativos.

Se os projetos são usados ​​por apenas um aplicativo, eles não deveriam ter sido feitos em primeiro lugar. Use namespaces. Salve-se o problema de referências circulares, sobrecarga de dll e confusão de projeto ao procurar arquivos.

Leia este artigo para obter uma explicação melhor e mais detalhada sobre o motivo: http://lostechies.com/chadmyers/2008/07/16/project-anti-pattern-many-projects-in-a-visual-studio- arquivo de solução /

E, como o artigo afirma, gostaria de receber qualquer pessoa que tenha um motivo válido para ter vários projetos além do compartilhamento de código no aplicativo para me dizer o que é, porque duvido que exista.

Didier A.
fonte
Os argumentos contrários no voto negativo serão apreciados.
Didier A.