E ai, pessoal! Tudo bem?

Primeiramente, gostaria de agradecer a todos que participaram da live sobre Blazor no canal Coding Night, e principalmente ao Renato Groffe e André Secco pelo convite para contribuir com conteúdo no canal.

Para quem não assistiu, segue o link para a gravação da live no YouTube:

Conforme mencionei na live, e dando continuidade ao assunto, estou iniciando esta série de artigos onde vamos construir uma aplicação mais complexa e funcional, sendo um aplicativo Web para controle de histórias e tarefas no Scrum ou quadro Kanban. Incluiremos o controle de capacidade do time, assim como um dashboard com o gráfico de Burndown.

Nos primeiros artigos, trataremos bastante da definição da aplicação, regras e arquitetura para construirmos algo testável e que agregue valor de verdade ao usuário. Portanto, devemos demorar algumas partes para começar a trabalhar com o Blazor, mas tudo por uma boa causa: um produto com qualidade. Então peço um pouco de paciência a todos.

Novamente, reforço o que já disse na live: o Blazor ainda é um projeto em fase experimental e não deve ser utilizado em aplicações de produção. Estamos desenvolvendo algo mais elaborado para fins de aprendizagem, não apenas em Blazor, mas também em arquitetura, uso do Entity Framework, cache, etc.

Bom, chega de papo e vamos começar!

Definindo do domínio e regras da aplicação

Vamos avaliar alguns requisitos importantes:

• Nossa aplicação deve possuir usuários, assim como times aos quais estes usuários pertencem.
• Para cadastrar features, histórias e tarefas, precisamos de iterações (ou Sprints, exemplificando com o Scrum para ficar mais claro).
• Os itens acima devem ficar abaixo de seus respectivos projetos.
• As colunas do quadro devem ser customizáveis (status diferentes), permitindo uma certa flexibilidade do fluxo de trabalho.
• Os artefatos (histórias, tarefas, etc) podem ter anexos; cada um pode ter seu fluxo de status customizado pelo tipo, também.

Com esses requisitos, podemos começar com o modelo abaixo:

Partiremos deste modelo para começar a trabalhar, mas durante o desenvolvimento vamos evoluir ele com algumas features extras. Afinal, o cliente pode solicitar melhorias já que seu negócio está sempre evoluindo.

Baseado neste modelo, vamos começar a criar nosso projeto com as classe de domínio. Inicialmente, vamos criar um projeto usando o template do Blazor, apenas para já gerar os projetos necessários, e vamos adicionando as demais camadas na solução, ok?

Criando a solução no Visual Studio 2017

Vamos iniciar criando a solução no Visual Studio 2017 através do template do Blazor.

Para isto, seu Visual Studio deve ter instalado o plugin ASP.NET Core Blazor Language Services. Para isto, acesse o menu Tools, e em seguida Extension and Updates.

Com o plugin instalado, vamos acessar o menu File, New, e em seguida Project. Nesta tela vamos navegar na opção .NET Core e escolher ASP.NET Core Web Application.

Os demais campos, como nome do projeto, solução e local para armazenar os arquivos, podem ser preenchidos como acharem melhor. Uma sugestão de nome é Blazor.Kanban.Web para projeto e BlazorKanban para o nome da solução. Ao clicar em OK, uma nova janela será aberta.

Escolheremos a opção Blazor (ASP.NET Core hosted). Após clicar em OK, teremos uma solução com três projetos criados.

• Blazor.Kanban.Web.Shared: este projeto possui todos os elementos que são comuns entre o back-end e o front-end. Nele, definimos nossas classes de domínio.
• Blazor.Kanban.Web.Server: este projeto possui toda a lógica que ficará no back-end, como repositórios, classes de negócios e outros, expondo nosso domínio (Shared) através de Web API, utilizando controllers. Este projeto também faz referência ao projeto Client, para servir de host das views compiladas em Web Assembly.
• Blazor.Kanban.Web.Client: este projeto é basicamente um projeto do tipo Razor Pages, que com algumas modificações compila as Views para Web Assembly, utilizando o Blazor. Isso produzirá um arquivo com extensão WASM, assim como DLLs utilizadas pelo projeto e algumas bibliotecas JavaScript para compatibilidade com browsers em versões não tão atuais. Estes serão disponibilizados pelo projeto Server, que além de API, serve de host para os arquivos estáticos do front-end.

Fechando a primeira parte

Para não ficar muito extenso, vamos considerar esta uma primeira parte.

Na próxima, vamos definir nossas entidades de domínio e o mapeamento para o banco de dados, através de repositórios.

Um abraço e até o próximo artigo!