Artigos

Arquitetura Monolítica Modular: Organização Modular de Pastas

Quando você está a desenvolver uma Aplicação Empresarial que será utilizada apenas pela empresa e os seus funcionários. Você não está a construir uma aplicação de escala global, ou não tem um caso para escalabilidade. Você não precisa de Micro-serviços e de todas as complexidades de infraestrutura que resultam destes. Ainda assim, você precisa ter boas bases para a sua aplicação. E se chegar o momento, você pode facilmente dividir as partes em serviços separados. Este artigo pretende expandir a proposta apresentada em Componentes do Software Empresarial: Caso Prático, relativamente a organização de pastas segundo os conceitos de Clean Architecture e Hexagonal Architecture. Aqui irei propor uma estrutura de pastas mais elaborada da que foi apresentada no artigo anterior. Devo ressalvar que as arquiteturas Clean e Hexagonal não se referem à organização das pastas, mas sim uma abstração lógica dos componentes de software, das suas responsabilidades, e das relações de dependência entre si. Aspectos Fundamentais a Considerar A organização de pastas deve estar alinhado com os conceitos de design de software, e uma das qualidades mais importantes terá a ver com a manutenção da aplicação ao longo prazo, e com a capacidade de evoluir, ou escalar, com o mínimo de esforço necessário. Separação de Responsabilidades: A estrutura de pastas deve refletir o princípio de separação de responsabilidades, em que diferentes componentes ou camadas do sistema são agrupados com base em suas responsabilidades. Arquitetura em Camadas: Organizar com base nas diferentes camadas, como por exemplo a camada de apresentação, a camada de negócios e a camada de dados. Módulos Funcionais: Identificar os módulos funcionais da aplicação e organizar as pastas de acordo. Cada módulo deve ter sua própria pasta com os seus componentes, como por ex. controllers, serviços, models e views. Reutilização de Código: Estrutura de pastas que promova a reutilização de código. Identificar os componentes comuns ou utilitários que podem ser compartilhados em diferentes partes da aplicação e colocá-los em pastas ou módulos separados. Escalabilidade e Crescimento: Considere a escalabilidade e o crescimento futuro do projeto. A estrutura de pastas deve ser capaz de acomodar novos recursos, componentes ou camadas sem se tornar excessivamente complexa ou confusa. Ela deve facilitar a adição ou modificação de funcionalidades à medida que o projeto evolui. Convenções de Nomenclatura: A estrutura deve seguir convenções claras e consistentes de nomenclatura para pastas e ficheiros. Facilitando na navegação do código e na compreensão do propósito de cada pasta ou ficheiros. Configuração e Recursos: Separar arquivos de configuração, recursos estáticos (como imagens ou ficheiros de estilo) e outros ficheiros não relacionados ao código-fonte em pastas apropriadas. Colaboração e Estrutura da Equipa: Considerar a estrutura da equipa de desenvolvimento e como eles colaboram no projeto. A estrutura de pastas deve estar alinhada com o fluxo de trabalho da equipe e facilitar o desenvolvimento simultâneo, controle de versão e processos de revisão de código.
Arquitetura Monolítica Modular: Organização Modular de Pastas

Artigos

Entity Framework Core

A Microsoft tem desenvolvido esforços no sentido de fazer o ASP.NET Core ser uma opção de excelência no desenvolvimento de aplicações, já temos indicadores que apontam progressos interessantes de realçar, um deles é o benchmarks partilhado também no próprio site, que aponta ASP.NET Core como mais rápido e consegue processar mais requests por segundo que NodeJS e JAVA. A Entity Framework Core faz parte do ecossistema, tem recebido contribuições da própria Microsoft e da comunidade, por ser open source diferentemente do Entity Framework, tudo isso, tem contribuído para uma rápida evolução Entity Framework Core, que já conta com várias novas funcionalidades que não fazem parte de Entity Framework. O que é o Entity Framework Core Entity Framework Core (EF Core) é um conjunto de bibliotecas criadas e mantidas pela Microsoft, ao contrário da Entity Framework, este é open source, recebe contribuições da comunidade, o que tem colaborado para uma evolução mais rápida que antecessor. EF Core possibilita que aplicações desenvolvidas em ASP.NET Core possam obter e persistir dados em base de dados de forma simples e clean. EF Core é uma Object-Relational Mapper (O/RM), criado para ser uma nova versão do Entity Framework mais leve, open source, multiplataforma, extensível e já conta com funcionalidade adicionais, segue alguns: DbContext pooling — possibilita reutilizar instâncias do contexto, cada instância de contexto é configurado vários serviços internos e objetos necessários para executar suas tarefas, a reutilização pode representar ganhos em situações de alto volume de requests por segundo; Alternate keys — que permite definir colunas com valores únicos; Global query filters — filtros aplicados a nível global; Entity Framework Core e base de dados EF Core suporta vários sistemas de gestão de base de dados como Oracle, SQL Server/Azure SQL Database, SQLite, MySQL, PostgreSQL, Azure Cosmos DB e In-memory (for testing). Conceitos importante nas aplicações com EF Core As aplicações que usam EF Core, usam alguns conceitos como: Database Context — é uma classe que faz o mapeamento dos objectos de base de dados e objectos da aplicação, configurações e dados e inicialização. A Database Context serve como uma ponte entre a aplicação e a base de dados para obter e persistir dados. Model — é a classe que é mapeado com uma tabela para obter ou persistir dados, o model é uma classe C# com configurações adicionais. Temos duas abordagens, para configurar as models: Data Annotations; Fluent API configurations;

Reduza bugs, vulnerabilidades, code smells, entre outros problemas em aplicações .NET Core, com esta ferramenta.

Na linha dos conteúdos abordados anteriormente, a qualidade do software é uma preocupação a se ter em conta pelas empresas e profissionais da área. Anteriormente falamos de testes que é um excelente aliado na busca pela qualidade. Todavia, existem outros aspectos que pretendemos dar ênfase neste artigo, como codigos seguros e a complexidades dos mesmo. Complexidade para leitura, como para incluir novas alterações de forma fácil. Talvez esteja a pensar, mas a revisão de código pode mitigar esses impactos. A proposta é não depender apenas de desenvolvedores, mas recorrer a uma ferramenta que faz a análise dos códigos e apresenta problemas relacionados com os pontos acima mencionados em minutos. Como bônus apresenta sugestões de correção. Sonarqube É uma ferramenta de análise de código que ajuda os desenvolvedores a entregar código de qualidade, seguro, consistentes, confiáveis e com baixo nível de complexidade. Possui suporte a mais de 30 linguagens de programação, pode ser integrado a pipeline de continuous integration. Desenvolvido na linguagem Java em 2006. Em termos de licenciamento possui versão grátis e outras versões pagas. Sonarqube possibilita identificar: Vulnerabilidade de segurança; Bugs; Duplicação de código; Nível de cobertura de teste; Complexidade de código que podem dificultar no processo de manutenção; Permite ainda, criar novas regras para assegurar que certos padrões sejam seguidos. Funcionamento A solução é composta por duas aplicações, um cliente que recolhe os dados do código fonte e os respetivos testes, outro servidor que faz processamento dos dados recolhidos e apresenta os relatórios e as sugestões de correção. No servidor pode ser feito as configurações e criação das novas regras. Demonstração Para efeitos de demonstração a proposta é instalar a versão Community Edition. O servidor vai ser instalado num container Docker, assim como uma base de dados PostgreSQL. Para facilitar segue um ficheiro Docker compose (docker-compose.yml) que, permite configurar e arrancar vários containers container ao mesmo tempo. O ficheiro deve ser criado com o nome docker-compose.yml, a sugestão seria criar uma pasta, dentro da pasta criar o ficheiro e executar os comandos a seguir.

Arquitetura Clean Hexagonal: Caso Prático

Este artigo é uma extensão do artigo teórico Componentes do Software Empresarial, que retrata a combinação dos conceitos de design de software, nomeadamente a Hexagonal Architecture e Clean Architecture. É necessário ler o artigo anterior para perceber os conceitos aqui aplicados, e os objetivos pretendidos. Desta vez focaremos essencialmente nas questões práticas, ou seja na implementação do design apresentado anteriormente. Proposta de Design O diagrama seguinte resulta de uma combinação dos ensinamentos das arquiteturas Hexagonal e Clean; e representa em detalhe o design pretendido para o nosso software. Este diagrama identifica de forma geral, simples e direta, todas as camadas do design, e as suas responsabilidades: Entities (ou domain) — Contém as regras principais do negócio. Use cases (ou application) — Contém as regras de orquestração ou as operações princiais da aplicação. Adaptadores de interface — Fazem a intermediação da aplicação com o mundo exterior (a infraestrutura). Infraestrutura (Frameworks, drivers) — O mundo externo, que podem ser aplicações, serviços, bibliotecas, APIs… Os entities e os use cases constituem o núcleo (core) da aplicação, a componente central da arquitetura (o hexágono) e o responsável por encapsular toda a lógica do negócio. A Perspectiva Hexagonal Na perspectiva da arquitetura Hexagonal a aplicação deve ser capaz de: Suportar várias tecnologias (base de dados, message brokers, serviços de emails, etc) Ser testado sem ter todas as tecnologias definidas Ser desenvolvida sem ter todas as tecnologias definidas A arquitetura (Hexagonal) possui dois lados essenciais: Lado esquerdo ou lado de user interface — direcionado aos utilizadores e às aplicações clientes. Possibilitado pelos Driving Adapters. Estes utilizarão a aplicação. Lado direito ou lado de data and service providers — direcionado para o acesso de dados e serviços. Possibilitado pelos Driven Adapters. Estes serão utilizados pela aplicação.

Desbloquea o poder dos testes em ASP.NET: aprimora a qualidade do software: xUnit e Coverlet II

Testes de software são cruciais para garantir a entrega de um produto de boa qualidade, oferecem adicionalmente um conforto na fase de manutenção, refatoração de código ou mesmo na mudança de elementos da equipa, além de outros benefícios elencados na parte 1. Conforme avançado na primeira parte, vamos criar um projecto com o respectivo projecto de teste com xUnit e Coverlet. Com vista dar corpo ao exemplo, vamos criar uma pasta para os projectos, na pasta vamos ter uma class library e o projeto de teste. Código a ser testado Na class library abaixo, vamos ter uma classe que possui um método que recebe uma string e valida se é um número e se o mesmo não possui mais de 10 caracteres. Teste com xUnit A seguir temos o projecto de teste que usa o xUnit, ao ser criado, já inclui a biblioteca coverlet. Para confirmar isso, depois de criar o projecto de teste, se abrirmos o ficheiro xUnitCoverletTest.csproj, teremos como uma das PackageReference o coverlet.collector. A classe de teste valida o resultado da execução do método. No nosso exemplo se o método receber uma string com apenas números e que não tenha mais de 10 caracteres é suposto devolver tue, caso contrário o resultado é false. Foi usado duas abordagens para testes, uma que permite passar vários inputs como parâmetro para testar ([Theory]) e outro sem parâmetros ([Fact]). O projecto de teste deve referenciar a nossa class library, para assim ser possível testar os métodos disponíveis na class library. O comando que se segue permite referência a class library. Para confirmar se ficou correto, pode-se abrir o ficheiro xUnitCoverletTest.csproj, conferir se existe uma tag de nome ProjectReference.