Voltando ao ASP.Net Webforms do ASP.Net MVC. Recomendar padrões / arquiteturas?

12

Para muitos de vocês, isso parecerá uma pergunta ridícula, mas estou perguntando, porque tenho pouca ou nenhuma experiência com ASP.Net Webforms - fui direto ao ASP.Net MVC.

Agora estou trabalhando em um projeto em que estamos limitados ao .Net 2.0 e Visual Studio 2005.

Gostei da separação clara de preocupações ao trabalhar com o ASP.Net MVC e estou procurando algo para tornar as formas da web menos insuportáveis. Existem padrões ou práticas recomendadas para quem prefere o asp.net MVC, mas está preso no .net 2.0 e no visual studio 2005?

asp.net-mvc

— jlnorsworthy
fonte

Obrigado por todas as sugestões, pessoal - gostaria de poder escolher mais de uma resposta.

— Jlnorsworthy

1

Espero que sua nova tarefa seja apenas para um projeto existente e não para algo que comece do zero. Existem muitas coisas básicas das quais você se tornará dependente e que estarão ausentes, como usar o Linq para consultas simples sobre coleções. Uma grande frustração virá de olhar para o HTML gerado e ver que não é nada como o que você esperava. Boa sorte e espero que você seja bem sucedido.

— Chris

7

Eu recomendaria o Model View Presenter (MVP). Usamos isso em um aplicativo WebForms recente, que aumentou nossa testabilidade e nos permitiu impor a separação de preocupações.

http://msdn.microsoft.com/en-us/magazine/cc188690.aspx é um ótimo artigo de Jean Paul Boodhoo sobre esse padrão; o download do código também é bom. Você pode achar que não precisa de DTOs e interfaces para DTOs.

Outro bom artigo é este no codeproject.com: http://www.codeproject.com/KB/architecture/ModelViewPresenter.aspx

Edit: também existe uma estrutura chamada WebForms MVP, mas eu não sei muito sobre isso.

— Ciaran
fonte

O Webvorms MVP parece muito legal, mas o projeto parece ter parado (última versão em 07/10). Não há uma grande quantidade de documentação ou tutoriais disponíveis

— jlnorsworthy

Também parece exigir o .NET 3.5 SP1, por isso pode não ser muito útil para você. No entanto, amostras e origem podem ajudá-lo a avaliar o padrão MVP.

— Ciaran

Bom ponto, eu nem percebi isso. Eu vou manter meu olho nesse projeto no caso em que eu tenho que fazer webforms com uma empresa que tem a tecnologia atual :)

— jlnorsworthy

4

Eu recomendaria que você entendesse o ciclo de vida da página do .net 2.0

Vale a pena assistir a esses vídeos, embora nem todos sejam gratuitos, mas pelo menos esse será um bom começo para você ... A questão é que isso lhe dará uma idéia do que pesquisar mais adiante.

— Carls Jr.
fonte

3

Como você já deve ter descoberto até agora, precisaria desaprender algumas coisas que aprendeu com o ASP.NET MVC (btw - o mesmo acontece quando uma pessoa do ASP.NET se interessa em aprender o ASP.NET MVC). Você ainda pode implementar o padrão MVC no ASP.NET, mas a separação de View and Model está muito desfocada no ASP.NET devido à arquitetura de postagem de evento / página.

Na minha opinião, a maior parte do seu novo aprendizado estará relacionada ao Ciclo de Vida da Página e Eventos e Controles. As coisas usuais Session, Cache, ViewState e DB interações permanecem as mesmas.

HTH ...

— sajoshi
fonte

2

Padrão do controlador frontal do checkout e implementação do controlador frontal no Asp.Net. Faça essas coisas apenas se o seu projeto for de bom tamanho. Fazer isso para um projeto pequeno não justifica o ROI.

Em um projeto pequeno, você pode tentar definir algumas diretrizes. Por exemplo - Nenhuma lógica de negócios, nenhuma sessão usa etc. no código anterior.

Veja o que melhor se adequa ao seu caso. De qualquer forma, tenha a tentação de fazer mais do que a engenharia.

— Pradeep
fonte

0

Nos dias sombrios do .NET 1.1, criei (acho que como todo mundo) uma espécie de sistema MVC para um aplicativo que foi assim.

Uma página foi criada para ser uma espécie de mestre 'falso'. Isso tinha algum encanamento para mostrar menus, scripts, estilos etc.

As 'visualizações' eram controles de usuário individuais.

Havia uma tabela com informações sobre cada visualização. Por exemplo, 'Produto' seria carregado ~/Controls/Product.ascxem um espaço reservado. A tabela também tinha um campo que continha o nome do tipo da classe de modelo (como se). Cada modelo implementou uma interface conhecida. Essa classe foi instanciada usando Activator.CreateInstance()e chamada para inicializar e depois foi passada para o próprio controle (inversão de controle?). O controle então chamou vários métodos para obter conjuntos de dados ou outros enfeites. A interface em si foi normalizada para ter os métodos CRUD usuais (leitura / gravação / lista / exclusão). Havia também uma camada DAL / ORM abaixo disso.

Não era bonito, mas funcionava bem. Era fácil testar e desenvolver, e a maioria dos desenvolvedores que entravam a bordo se dava bem rapidamente. Acima de tudo, era relativamente simples de criar.

— kprobst
fonte