Como estritamente você segue a arquitetura n-tier e separação de interesses entre as camadas em seus projetos?

Question

Suponho que a maioria dos desenvolvedores tem uma idéia de arquitetura multi-camada. Temos DAL (camada de acesso a dados), temos BLL (camada de lógica de negócios) e em algum lugar perto do fim da estrada temos o nosso UI. Se você tem um projeto que de alguma forma segue estes princípios, você manter (ou pelo menos tentar) para manter / colocar as coisas onde elas pertencem conceitualmente? Estou especialmente interessado em grandes aplicações da empresa onde você trabalha em conjunto com muitas outras pessoas. É claro que você pode fazer o que quiser com o seu projeto brinquedo privada, inventar qualquer tipo de uma arquitetura e cumpri-lo. Não é tão fácil com grandes projectos onde muitas pessoas contribuíram para o software ou bagunça geral.

Por exemplo, aconteceu de eu ver as coisas como componentes de interface do usuário que vão diretamente ao banco de dados para buscar alguns "perdidos" dados adicionais que BL não fornecem, também ambos UI e BL que trabalham com elementos de baixo nível como campos de tabela em que, na minha opinião eles devem delegar essas operações ao nível mais baixo nomeadamente DAL. Foi especialmente triste quando depois de discutir as coisas com o cara desenvolvedor sênior vi que ele não vê um problema com tudo isso.

É claro que podemos assumir mim e quem compartilha meu ponto de vista estão apenas a ser perfeccionistas, mas eu vi claramente uma conseqüência muito disadvantegous em que ele me levou prolongada períodos de tempo em algumas das minhas tarefas para rastrear todos os "paralelo" rotas que os dados são viajam de e para o banco de dados e para identificar quem e de que forma podem agora ser afetados pela nova funcionalidade que eu implementado. A forma como eu vejo, estes são aumentou ainda mais os custos de desenvolvimento / manutenção sobreponderação algumas economias quando alguém decidiu cortar rapidamente o material e fechar a tarefa mais rapidamente possível.

Você projeta "puro" ou eles abandonaram a idéia de manter a linha clara entre as camadas muito tempo atrás? Se você ainda mantendo-direita, como você lida com os colegas que não entendem estas coisas ou não se preocupam com eles apenas a construção de soluções "personalizadas" e hackers hacks o tempo todo? Ou em algum ponto no tempo que você parou de lutar com o moinho de vento e aceitou como sua punição ?. EDIT: um pouco surpreso que muitas pessoas não se interessou pelo problema. É que o sinal o mais não me importo?

Answer 1

O mais complicado o nosso aplicativo obtém, a separação mais importante de preocupações torna-se.

A 100 klocs, a aplicação foi uma grande bolha, tanto código negócios em classes de formulário como em qualquer outro lugar e chamadas em métodos de formulário a partir das classes de negócio. Com muito choro e ranger de dentes, nós separamos a lógica de negócios da lógica de exibição. Qualquer classe que precisava para notificar o usuário de seu progresso levantou um evento que foi afundado pela UI. E, por um tempo, tudo estava certo com o mundo.

Cerca de 200 klocs, nós adicionamos uma camada de dados. A arquitetura do nosso aplicativo era tal que a maioria dos nossos dados foram processados ??assim que ele entrou e imediatamente descartado. A maioria das informações de configuração foi armazenado no aplicativo de terceiros com os quais a nossa compartilhada uma relação simbiótica. Mas, configurações estavam começando a se acumular em todos os tipos de cantos ímpares. Nós acabou com três sistemas de gerenciamento de configuração, todos primorosamente tecidas a lógica de negócios. Com uma extensa reescrita, fomos capazes de separar as informações de configuração em sua própria camada e a manipulação de streaming de dados em outra camada.

Perto da linha kloc 250, decidimos terminar nosso relacionamento com o fornecedor de terceiros e fazer a nossa aplicação ficar sozinho. Começamos uma reescrita maciça e, pela primeira vez, adicionou um banco de dados real para a nossa aplicação. Porque nós tivemos linhas claras entre informações de streaming, armazenamento de dados e lógica de negócios, esta foi uma integração bastante transparente.

Agora, se aproximando 500 klocs, nós estamos movendo o aplicativo para uma arquitetura baseada em grid. Não só o UI ser separada da lógica de negócios em um computador diferente, o cálculo real das cotações e pedidos que a aplicação envia será carga equilibrada e espalhar-se para maximizar a eficiência. Isso seria impossível sem uma arquitetura n-tier.

Em cada fase de crescimento, ou foram auxiliados por uma separação limpa ou dificultado por nossa própria confusão de comunicação, dados, negócios e UI. Provavelmente não tem sido uma preocupação mais importante do que a separação na criação desta aplicação.

Answer 2

Essa é uma ótima pergunta! Algo cada desenvolvedor ASP.Net precisa pensar. Você provavelmente vai ter um monte de respostas, eu incentivar essas idéias de senso comum básico.

- Considere simplicidade e velocidade de entrega como parte de uma arquitetura de "bem-sucedida", não apenas "pureza". Tente equilibrar entre segurando a ideais arquitectónicos, e ser prático.

- Em geral, parece fazer sentido para dividir o código em camadas como você menciona. Gostaria de sugerir que embora a lógica específica páginas, poderia ser deixada na página, se é mais simples / mais rápido - por que criar objetos de negócios genéricos para código que é usado apenas em um lugar. Como tem sido dito "otimização prematura é a raiz de todo mal.”.

-. Mantenha as camadas e complexidade ao mínimo para reduzir o tempo de codificação e melhorar a legibilidade e manutenção

Há muitos puristas neste site que gostam de fazer arquitetura para o site da arquitetura - arquitetura uso como uma ferramenta para fornecer uma solução para um problema de negócios, não apenas como uma forma de arte para o seu próprio bem, que seja um ferramenta útil em vez do que usando você.

Answer 3

Mantenha as preocupações separado. É muito, muito importante. Não misture UI com Biz e Biz com camada de dados. Trabalho com a abstração. Trabalhando com a abstração também faz o teste (teste de unidade) mais fácil (Mock-los). Eu mantenho estritamente cada camada onde ele pertence. Lembre-se que o maior custo de qualquer projeto é de manutenção. Se misturar as preocupações em seguida, manutenção vai se tornar um pesadelo.

Answer 4

Nós temos um aplicativo WinForms, e um aplicativo ASP.NET. Ambos usam a mesma Business Objects projeto (cerca de 140 classes).

O projecto WinForms consiste de cerca de 350 classes de formulário e de controlo do utilizador, e um número muito pequeno (<10) destes necessidade metadados sobre si a partir da base de dados.

O projeto ASP.NET tem cerca de 100 páginas .aspx.

Nós temos uma camada de acesso de dados que consiste em 5 classes, que se preocupam com ADO.NET, fios e transações. Eles convertem solicitações da Business Objects em chamadas SQL Server.

As camadas de interface do usuário (com exceção das poucas classes que precisam de metadados sobre a forma dimensionamento) fazer nenhum acesso de banco de dados em tudo. Mesmo as poucas exceções passar pelo DAL como qualquer outra coisa.

A camada de negócio não sabe nada sobre o funcionamento interno da camada de acesso a dados, e quando ele precisa de dados, só já chama métodos públicos sobre as classes DAL.

Eu não sou de todo um fundamentalista quando se trata deste tipo de coisa, mas nunca necessário para cantos cortados em um presente.

Assim, em breve, 100% puro. É simplesmente sempre funcionou melhor para fazê-lo direito.

Nós teríamos que ter um inferno de uma boa razão para se afastar isso agora.

Answer 5

Code Monkeys e puristas são muito parecidos com qualquer outro extremista na vida.

Temos extrema direita e extrema esquerda. Muito poucas pessoas são exatamente um ou outro e eles encontrar um bom meio termo onde se sentam. Se não fosse para os extremistas não saberíamos onde as fronteiras se encontram.

Quanto ao código de maneira que eu vá. Eu escuto o puristas maneira de fazê-lo. Eu ver os macacos de código indo sobre seus métodos. Eu uso a minha experiência de escolher um meio termo que me dá a quantidade certa de flexibilidade e capacidade de gerenciamento, juntamente com o tempo que preciso para produzi-lo ea quantidade de dinheiro que eu estou indo realmente para conseguir para fazê-lo.

Answer 6

Quanto maior for o código, quanto maior o tempo de vida, o mais pessoas diferentes trabalhos do código (ambos simultaneamente ou durante o tempo de vida) o mais importante separação ela em camadas é. No início, parece ser um pouco mais trabalho desnecessário, mas no longo prazo, que paga por si mesmo várias vezes.

Como para impor a separação: É por isso que o seu programador de chumbo ou arquiteto técnico precisa de boas habilidades macias, bem como habilidades técnicas puros. Você pode tentar impor a separação tecnicamente (veja abaixo), mas no final, você precisa convencer (ou coagir) seus desenvolvedores para manter o retrato grande limpo.

Mas isso não quer dizer que os meios técnicos para impor a separação não tem nenhum uso. Na verdade, eu achei que garantir que as "chamadas transfronteiriças" são um pouco difícil de fazer vai fazer as pessoas passam mais tempo pensando sobre o que eles realmente precisam na-border-interface de cruz, levando a interfaces mais limpas. Não importa se a dificuldade é técnica (porque você tem que usar COM ou CORBA) ou qualquer outra coisa (que você tem que preencher um formulário 7 página em triplicado).