Acho que todo desenvolvedor, quando chegou a um novo projeto, achou que seria bom voltar no tempo e dizer aos pais do seu projeto que os padrões não deveriam ser apenas solicitados na entrevista, mas também aplicados ao projeto real, mas eu seriamente.
Em particular, esse provavelmente é um padrão, mas uma regra muito boa é que a marcação deve ser separada do código. Isso se aplica aos bons e antigos formulários da Web, Asp.Net MVC - mais alguém escreve a marcação no Razor?), E o Angular é popular em uma empresa dura.
Se você passou do desespero pela frente dos enders e mudou-se para o novo e angular Angular and React, então ...
Sim, senhores, os desenvolvedores de back-end, tivemos novamente a esperança de que o conhecimento adquirido ao longo dos anos não fosse perdido na cabeça. E essa esperança é a tecnologia Blazor da Microsoft.
Tendo aberto o projeto padrão que o estúdio cria ao criar o projeto Blazor e depois analisado vários artigos, pensei que tudo é realmente tão ruim e que o código e a marcação estão sempre no mesmo arquivo, como por exemplo aqui (daqui em diante todos os exemplos serão mostrados com base em Projeto de modelo do Blazor Server App do Visual Studio 2019 com o .Net Core 3.1 instalado):
Nada confunde aqui?
Na minha opinião, tudo o que é preenchido com vermelho tem pouco a ver com o conteúdo que esse componente representa e você precisa se livrar dele. Porque
- Bem, primeiro, o desenvolvedor front-end que trabalhará com você ao mesmo tempo nesse controle ficará um pouco confuso com símbolos que são incompreensíveis para ele e toda vez que ele será cauteloso e fará perguntas quando precisar alterar algo no código enquadrado pela marcação Razor .
- Obviamente, os frontenders serão cuidadosos, mas com certeza você encontrará periodicamente o fato de que, após algumas manipulações, sua página não funcionará conforme o esperado ou simplesmente não funcionará.
- Se você acha que os desenvolvedores de front-end não serão necessários, porque agora tudo pode ser escrito em C #, então você está enganado. De qualquer forma, você precisa estilizar o controle, e isso será feito pelo desenvolvedor front-end ou pelo tipógrafo que geralmente não sabe o que é C #.
- No começo, parecerá que o código é pequeno e não atrapalha muito o layout, é enganoso. Em um projeto em crescimento, você rapidamente passa do estágio, demonstração de tecnologia para "caramba, o que acontece aqui". Eu sempre me deparo com o fato de que, no SQL Web Controls ou diretamente na página .cshtml, uma consulta SQL foi postada no banco de dados; sim, não estou brincando. Muitas vezes, desenvolvedores experientes que ontem o torturaram em uma entrevista de segurança social, já conhecendo os princípios do SOLID, estão escrevendo a lógica dos negócios amanhã, diretamente na marcação.
Acho que já o assustei o suficiente, agora vou lhe dizer como evitar os problemas acima, mais isso é feito com muita simplicidade. E será ótimo se você seguir as seguintes abordagens como regra ao criar qualquer novo componente do Razor. Então, a primeira abordagem.
Classe base
A primeira e, até recentemente, a única abordagem.
Você cria uma classe base na qual toda a lógica de exibição será localizada, para o controle do exemplo acima. Crie um novo arquivo usando o modelo
[Nome do Controle] .razor.cs
Aqui o estúdio virá em nosso auxílio e criará a partir de dois arquivos, como na figura abaixo:
Como você pode ver, o estúdio é bastante inteligente e se entende o que você quer dele. O controle foi agrupado com o arquivo no qual queremos colocar nosso código.
Se você abrir um novo arquivo agora, o nome da classe FetchData será sublinhado com uma linha ondulada vermelha, tudo é verdade, porque apesar do fato de que no FetchData.razor você não verá declarações de classe com o nome FetchData em nenhum lugar , mais tarde, após a compilação do projeto, mostrarei é mais baixo e, portanto, o nome da classe FetchData já está reservado. Não temos escolha a não ser usar a convenção de que colocaremos a lógica de exibição (e somente ela !!!) na classe FetchDataBase, ou seja, o nome da classe será formado pelo modelo:
Base [ControlName]
Obviamente, você pode ficar confuso e escrever seu próprio analisador estático, que verificará esses arquivos para cada componente. Por que não?
Em seguida, precisamos herdar essa classe do ComponentBase . Não esqueça de adicionar
using Microsoft.AspNetCore.Components ;
E aqui está o que temos:
Uau, a turma está pronta para transferir a lógica de exibição aqui, que agora temos a oportunidade de escrever completamente em C #, não é felicidade? :)
Mas enquanto o próprio componente Razor não sabe nada sobre o nosso arquivo, apenas o Visual Studio sabe que eles têm algo em comum.
Então, faça o seguinte truque:
Herdamos o componente Razor da classe FetchDataBase .
Deixe o código C # que ainda existe no FetchData.razor não incomodá-lo.
No momento, transferiremos toda a lógica de exibição para o chamado código por trás do arquivo:
O que aconteceu, bem, primeiro adicionamos o uso de -e. Nos controles do Razor, você praticamente não os verá, porque é habitual adicioná-los ao _Imports.razor . Já foram adicionados alguns dos mais usados.
Em seguida, injetamos na propriedade, como você pode ver, nosso DI favorito funciona muito bem.
Você só precisa marcar a propriedade implementada com o atributo [Inject] . No componente Razor, foi marcado como Injetar . Ou seja, as mudanças são mínimas.
Bem, então segue a propriedade, na qual carregamos as informações exibidas, elas devem ser pelo menos protegidas (porque o controle Razor herda da classe atual). Ou público, se você decidir inicializá-lo de fora, nesse caso, você ainda precisará marcá-lo com o atributo [Parâmetro] . Nas versões anteriores do Blazor, ele era bastante protegido , mas agora o analisador de estúdio o repreende.
Em princípio, você pode adicionar um construtor a essa classe e fazer algum trabalho lá, mas isso não é recomendado, é melhor colocar toda a lógica de inicialização no método OnInitializedAsync ()
Isso é tudo o que resta no FetchData.razor
Havia marcações intercaladas do Razor, mas como poderia ser diferente, ainda precisamos exibir nossos dados de alguma forma. Mas o código C # puro desapareceu completamente. E isso é ótimo na minha opinião. Aconselho que você siga inicialmente uma abordagem semelhante e, em seguida, nem você nem seus colegas irão assumir sua cabeça quando seu controle aumentar para tamanhos grandes.
O mais importante é se funciona, agora vamos verificar:
Ótimo, é como se eles não quebrassem nada =)
Classe parcial
E assim a segunda abordagem, que apareceu recentemente ( https://docs.microsoft.com/en-us/aspnet/core/blazor/components?view=aspnetcore-3.1#partial-class-support ), mas provavelmente substituirá completamente anterior. A pedido dos trabalhadores, o .Net Core 3.1 adicionou a capacidade de criar uma classe parcial para os controles do Razor. Portanto, deixamos quase tudo como está na abordagem anterior, mas agora não precisamos herdar do ComponentBase, e a classe pode ser chamada da mesma que o componente, ou seja, sua assinatura será a seguinte:
classe parcial pública [ComponentName]
Como você pode ver abaixo, as alterações são mínimas. No código por trás, nos livramos da herança do ComponentBase e marcamos a classe como parcial
O arquivo de marcação também foi um pouco simplificado, também nos livramos da herança do FetchDataBase, essa classe deixou de existir devido à sua inutilidade.
Como você pode ver, existem duas abordagens para manter sua marcação limpa. Qual você escolhe depende de você. Infelizmente, seria bom para o estúdio gerar código-behind imediatamente ao criar um novo componente. Agora, isso está sendo discutido ativamente e, como dizem os desenvolvedores, no futuro essa probabilidade será adicionada se houver uma demanda, e certamente será.
Então agora o que o nosso componente Razor se transforma:
É familiar, não é?) Todo mundo que criou seus componentes do Razor Asp.Net MVC encontrará muito familiar o conteúdo do arquivo gerado automaticamente.
Espero que você tenha aprendido um pouco mais sobre o Blazor hoje no meu primeiro artigo sobre Habr. Deixe abaixo críticas, perguntas e solicitações de novos artigos =)