Há algum motivo negativo para usar uma solução N-Tier?

Question

Sou muito novo na minha empresa (2 semanas) e estamos iniciando uma nova plataforma para nosso sistema usando .NET 3.5 Team Foundation da DotNetNuke.Nosso "arquiteto" está sugerindo que usemos um projeto de classe.É claro que respondo com uma arquitetura de "3 camadas" (projetos de classe de negócios, dados e Web).

Existe alguma desvantagem em usar essa arquitetura?Os prós seriam a separação do código dos dados, mantendo os objetos de classe longe do seu código, etc.

Answer 1

Acho que uma grande desvantagem é que o volume extra de código que você precisa escrever, gerenciar e manter para um pequeno projeto pode ser apenas um exagero.

Tudo depende do que é apropriado para o tamanho do projeto, a vida útil esperada do projeto final e o orçamento!Às vezes, embora fazer as coisas “corretamente” seja atraente, fazer algo um pouco mais “leve” pode ser a decisão comercial certa!

Answer 2

uma equipe inexperiente tende a levar mais tempo para construir três camadas. É mais código, portanto, mais bugs.Mas estou apenas bancando o advogado do diabo.

Answer 3

Eu estaria pressionando fortemente pela abordagem de N camadas, mesmo que fosse um projeto pequeno.Se você usar uma ferramenta ORM como codesmith + nettiers você poderá configurar rapidamente os projetos e desenvolver códigos que resolvam seus problemas de negócios rapidamente.

Me mata quando você inicia um novo projeto e passa dias sentado girando rodas falando sobre como a "arquitetura" deve ser arquitetada.Você quer gastar tempo resolvendo o problema de negócios, não resolvendo problemas que outras pessoas resolveram para você.Usar um ORM (realmente não importa qual, basta escolher um e segui-lo) para ajudá-lo a obter tração inicial ajudará a mantê-lo focado nos objetivos do projeto e não o distrairá tentando resolver problemas de "arquitetura".

Se, no final do dia, o arquiteto quiser adotar a abordagem de projeto único, não há razão para que você não possa criar uma pasta app_code com uma pasta BLL e DAL para separar o código por enquanto, o que o ajudará a migrar para um Solução N-Tiered posteriormente.

Answer 4

Porque você quer o capacidade de ser capaz de distribuir as camadas em diferentes camadas físicas (eu sempre uso "camada" para física e "camada" para lógica), você deve pensar duas vezes antes de colocar tudo em uma classe porque você terá grandes refatorações para fazer se ou quando você precisar começar a distribuir.

Answer 5

Como acontece com qualquer coisa, a abstração cria complexidade e, portanto, a complexidade de fazer N camadas deve ser devidamente justificada, por exemplo, as N camadas realmente beneficiam o sistema?Lá vai Serão sistemas pequenos que funcionarão melhor com N camadas, embora muitos deles não funcionem.

Além disso, mesmo que seu sistema seja pequeno no momento, você pode querer adicionar mais recursos a ele posteriormente - sem usar N camadas poder constituem uma espécie de dívida técnica de sua parte, então você tem que ter cuidado.

Answer 6

A única desvantagem é a complexidade, mas é realmente difícil adicionar alguns objetos de domínio e vinculá-los a uma lista deles, em vez de usar um conjunto de dados.Você nem precisa criar três projetos separados, você pode apenas criar 3 pastas separadas dentro do aplicativo da web e atribuir a cada uma delas um namespace como YourCompany.YourApp.Domain, YourCompany.YourApp.Data, etc.

A grande vantagem é ter uma solução mais flexível.Se você começar a escrever seu aplicativo como um aplicativo centrado em dados, acoplando fortemente suas páginas de formulários da web a conjuntos de dados, acabará fazendo muito mais trabalho posteriormente, migrando para um modelo mais centrado no domínio, à medida que sua lógica de negócios cresce em complexidade.

Talvez no curto prazo você se concentre em uma solução simples, criando objetos de domínio muito simples e preenchendo-os a partir de conjuntos de dados, então você pode adicionar lógica de negócios a eles conforme necessário e construir um ORM mais sofisticado conforme necessário, ou usar o nhibernate.