Melhor arquitetura para aplicativos ASP.NET WebForms


10

Eu escrevi um portal ASP.NET WebForms para um cliente. O projeto meio que evoluiu, em vez de ser adequadamente planejado e estruturado desde o início. Conseqüentemente, todo o código é agrupado no mesmo projeto e sem nenhuma camada. Agora, o cliente está satisfeito com a funcionalidade, portanto, gostaria de refatorar o código de modo a ter confiança em liberar o projeto. Como parece haver muitas maneiras diferentes de projetar a arquitetura, gostaria de algumas opiniões sobre a melhor abordagem a ser adotada.

FUNCIONALIDADE

O portal permite que os administradores configurem modelos HTML. Outros "parceiros" associados poderão exibir esses modelos adicionando o código IFrame ao site. Dentro desses modelos, os clientes podem registrar e comprar produtos. Uma API foi implementada usando o WCF, permitindo que empresas externas também fizessem interface com o sistema. Uma seção Admin permite que os administradores configurem várias funcionalidades e visualizem relatórios para cada parceiro. O sistema envia faturas e notificações por email aos clientes.

ARQUITETURA ATUAL

Atualmente, ele está usando o EF4 para ler / gravar no banco de dados. Os objetos EF são usados ​​diretamente nos arquivos aspx. Isso facilitou o desenvolvimento rápido enquanto eu escrevia o site, mas provavelmente é inaceitável mantê-lo assim, pois está acoplando firmemente o banco de dados à interface do usuário. Lógica comercial específica foi adicionada às classes parciais dos objetos EF.

QUESTÕES

O objetivo da refatoração será tornar o site escalável, de fácil manutenção e segurança.

  1. Que tipo de arquitetura seria melhor para isso? Descreva o que deve estar em cada camada, se devo usar o padrão DTO / POCO / Active Record etc.

  2. Existe uma maneira robusta de gerar automaticamente DTOs / BOs para que quaisquer aprimoramentos futuros sejam simples de implementar, apesar das camadas extras?

  3. Seria benéfico converter o projeto de WebForms para MVC?


11
Solte cedo, solte frequentemente. Sugiro que seu cliente não se importe tanto se você não tiver problemas comerciais tangíveis para apresentar (por exemplo, é inseguro). Talvez você deva limpar um pouco (certifique-se de que seja portátil) e liberá-lo, depois tome isso como uma iniciativa de longo prazo - para se transformar em MVC ou similar.
gahooa

2
Não altere a tecnologia do projeto em funcionamento para a nova tecnologia xyz apenas porque ela existe, especialmente se o seu projeto estiver funcionando corretamente. Se estiver funcionando, não quebre. Os negócios não se importam com o código. Funcionalidade é tudo o que importa no final do dia.
NoChance

ok, isso é verdade, no entanto, minha preocupação é que, uma vez lançada, será mais difícil refatorar por causa do risco de quebrá-la quando as apostas forem muito maiores. Portanto, estaríamos presos a um código que não é tão sustentável e mais difícil de depurar etc. Fiquei tentado a aprender / converter para MVP, mas isso parecia muito trabalho. Até agora, eu apenas o converti em camadas de DAL, Domínio e UI, que parecem mais organizadas e ainda permitem o RAD inevitável que será necessário enquanto o projeto for jovem. Um dia, se necessário, posso expandir para MVP ou MVC, suponho - depois de ter tempo suficiente para aprender como tudo funciona.
homem pilha

O que se sente confuso ainda é: 1) EF objetos na interface do usuário (código por trás de arquivos na camada UI)
Homem pilha

(2) Lógica de negócios em objetos EF estendidos que precisavam ir na camada DAL (não percebiam que as classes parciais tinham que estar no mesmo assembly) (3) Lógica de negócios nos arquivos aspx.cs na camada da interface do usuário. No entanto, parece que muitas vezes existem compromissos quando se trata de arquitetura, mas este é certamente um passo à frente. Eu sinto que isso é aceitável para o 1º lançamento e, com o passar do tempo, podemos reavaliar nossa abordagem. Obrigado por sua ajuda a todos. É bom ter um pouco de direção, pois essa área é muito subjetiva.
homem pilha

Respostas:


5

O padrão ASP.NET MVP é a melhor arquitetura para um aplicativo de formulários da Web ASP.NET de longo prazo . Está entrando em jogo com o conceito de "separação de preocupações", que é de fato uma tendência por trás dos padrões de MV *.

A pergunta sobre por que usá-lo? - abordado em detalhes nesta postagem - ASP.NET MVP


O problema é que seria necessário muito trabalho para refatorar o projeto para o MVC ... se eu o mantiver como um aplicativo WebForms com Camada de Domínio (código primeiro, POCO), Camada de Acesso a Dados (somente contexto db) e interface do usuário, você considera isso um projeto aceitável para produção? Mais tarde, poderíamos considerar convertê-lo para MVC, suponho.
stack man

Bem, é um padrão MVP (model-view-apresentador) e NÃO um MVC (model-view-controller).
Yusubov 03/07/2012

11
oh desculpe - eu interpretei errado. Obrigado - vou ler sobre o design do MVP.
homem pilha

nenhum problema, eu espero que você vai encontrar o que você procura :)
Yusubov

Parece que a conversão para MVP também seria uma grande mudança. O cliente deseja liberar muito em breve, então você acha que a arquitetura DAL / DA / UI acima mencionada (embora não tão ideal quanto o MVP) seria aceitável para esse tipo de aplicativo? Depois do lançamento, poderíamos ver a mudança para o MVP na v2.
homem pilha

1
  1. Use o padrão MVP para separar, lógica e interface do usuário, para que no futuro você possa mudar para uma tecnologia de interface do usuário diferente reutilizando a lógica existente
  2. Use o padrão de repositório entre BL e DAL para poder mudar para qualquer RDBS reutilizando a lógica de negócios
  3. traga camadas separadas (DLLs) para BO e DAL, o que está minimizando a manutenção.

Não sei por que alguém votou negativamente nesta questão. Para ser honesto, esta é a resposta mais concisa. 1
Greg Burghardt

0

Como ElYusubov mencionou, o padrão MVP pode ser ótimo.

O conceito-chave está retirando a maior parte ou toda a sua lógica do code-behind. A lógica não deve estar vinculada a uma página. E se você precisar reutilizar a lógica de uma página em outra? Você será tentado a copiar e colar. Se você estiver fazendo isso, seu projeto se tornará sustentável.

Portanto, para iniciantes, comece a refatorar sua lógica a partir do code-behind e a coloque em uma camada de negócios. Se você conseguiu extrair toda a lógica do code-behind, poderia implementar as interfaces necessárias para ser um verdadeiro MVP.

Verifique também se o acesso aos dados está separado da lógica de negócios. Crie uma camada de dados e comece a refatorar também nesse sentido. Como você está usando o EF4, isso é menos problemático, já que o EF já deve ter esse fim separado. Você poderá mover facilmente todos os seus arquivos EF para outro projeto e simplesmente adicionar uma referência aos projetos que precisam dele. O benefício adicional é que você pode precisar fazer referência ao seu modelo de dados em outros projetos.

Para evitar ser sobrecarregado, refatorar um pouco de cada vez. Sempre que você tocar em um pedaço de código, considere refatorá-lo. Se você fizer isso, com o tempo, seu projeto poderá se tornar mais sustentável.

Editar

Você perguntou sobre a herança do código por trás de uma classe de lógica de negócios. Isso não pode ser feito porque o código por trás da página "é-a". O C # não permite herança múltipla, portanto, a classe code-behind não pode ser uma página e um objeto personalizado. Você precisa separar conceitualmente a lógica. Provavelmente, o código no seu code-behind está fazendo muitas coisas diferentes. Uma classe deve fazer uma coisa e apenas uma coisa. Tente e pense sobre como você pode conceitualmente extrair a funcionalidade existente. Por exemplo, digamos que você tenha uma página de registro e esteja coletando informações do usuário. Você provavelmente tem um botão chamado registrar e um evento de clique associado a esse botão. Nesse caso, você está salvando as informações do usuário e fazendo o processamento necessário. Você pode criar um objeto de registro para lidar com toda essa lógica.

Isso não é apenas uma separação mais limpa, mas também pode ser uma maneira de auto-documentar seu código. Quando alguém lê o seu código, ele vê você chamando um objeto de Registro para saber exatamente o que está acontecendo.

Se você quisesse seguir rigorosamente o padrão MVP, em vez de passar os parâmetros para o objeto Registration, o code-behind implementaria uma interface. A implementação da interface mapeará essencialmente todos os objetos de exibição (campo de texto etc.) para a interface. por exemplo, public string FirstName {get {return txtFirstName.Text; }}

Feito isso, você pode passar a página para o objeto Regisration

Registration.RegisterUser (this);

E esse método RegisterUser usaria a interface como parâmetro

public bool RegisterUser (usuário IUser) {user.FirstName ...}

interface pública IUser {public string FirstName; }

Se esse MVP parecer confuso, concentre-se na refatoração e saiba que o objetivo de tudo isso é maximizar a reutilização de código. Não existe desde que se repita. Esse é o diretor DRY .


Obrigado por suas dicas úteis. Sim, certamente fiquei um pouco impressionado com isso. Parece-me que o MVC seria o melhor padrão para usar, mas o MVP seria mais fácil de alcançar e seria o próximo melhor padrão. Eu sempre usei o código por trás dos arquivos, sempre me preocupava sobre como a lógica de negócios pode ser separada da apresentação ... para poder mover meus arquivos .aspx.cs para a camada de domínio e ter uma declaração hereditária no aspx ? Certamente terminar com 3 camadas me deixaria confortável em lançar a 1ª versão - então eu posso melhorá-la a partir daí.
homem pilha

Responderei ao seu comentário na minha resposta. Sinta-se livre para upvote minha resposta se você achou útil
codificador
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.