Asp.Net Boilerplate — Um Framework pouco conhecido… ainda.
Quando me foi oferecido um emprego para trabalhar com desenvolvimento web utilizando tecnologias Microsoft, eu fiquei com um pé atrás. Depois de 6 meses, minha opinião talvez tenha mudado um pouco.
Quando eu comecei a trabalhar, logo de cara me foi apresentado esse framework chamado de Asp.Net Boilerplate. Eu até me considerava um cara bem antenado ao mundo dos frameworks open-source mas nunca tinha ouvido falar desse. De Asp.net eu só havia visto CRUDs em artigos como esse aqui no Medium.
Um pouco de história
Acho relevante contar um pouco de história antes de contextualizar o framework para que se possa ser feito uma análise melhor.
Open Source
Até o final da década de 2010, a Microsoft liderada por Steve Ballmer era extremamente contra tecnologias open source. E isso já havia sendo visto também com Bill Gates a frente da empresa, com algumas opiniões publicas bem pesadas por trás disso.
A partir dos primeiros anos de 2010, quando o CEO foi trocado, para o então Satya Nadella, deu início a entrada da Microsoft ao mundo do open source. Em 2014 eles abriram o código do .NET framework, criaram o Visual Studio Code e em 2016 foi lançado o Asp.net Core. Além da compra do GitHub em 2018.
Hoje em dia ela é reconhecida com uma forte contribuída do movimento open source. Mas lembrem-se de uma coisa, isso tudo não é porque ela é uma empressa “cool” mas sim porque isso trás mais dinheiro.
Se quiserem ler mais sobre isso, a Wikipedia tem um ótimo artigo falando sobre isso.
Asp e Asp.net
O Asp surgiu em 1996 como um server-side script engine. Ele atendia bem ao que se propunha na época mas logo perdeu espaço e em 2002 foi lançado Asp.net. Tudo que o Asp já oferecia agora com o poder do .NET framework 1.0. Nessa época, como já mencionei o framework era fechado e tinha que ser pago uma taxa para o seu uso.
O surgimento do Asp.net Boilerplate
Em 2013, Halil İbrahim Kalkan detectou um problema: Beleza, temos um ecossistema bem maduro para trabalhar. Mas ainda precisamos reescrever cache, um sistema de notificação, logs, os jobs, tradução para todo novo sistema. Foi pensando nisso que esse fera turco criou um framework com o nome de boilerplate (boilerplate são textos/códigos que podem ser reusados em contextos diferentes). Nele já temos quase tudo de comum nas aplicações enterprise atuais. E é todo implementado pensando em DDD e Solid.
Isso tudo ainda foi feito em cima do Asp.Net framework.
Asp.Net Core
Em 2016, a Microsoft decidiu reescrever todo .NET framework (já que ele só rodava no Windows) e lançou o Core. Com ele é possivel desenvolver em qualquer plataforma.
Seguindo a onda, a equipe do ABP (Asp.net Boilerplate) logo lançou a sua versão usando Asp.net Core. Como o código do ABP é apenas de infraestrutura, essa migração não foi dificil.
O framework
É importante salientar que o ABP não é nada além de códigos escritos em cima do Asp.net Core, que auxiliam os desenvolvedores. É apenas o código base do Asp.net Core em que foram escritas bibliotecas comuns. Ele é a cereja que falta na torta pura da Microsoft.
Como sempre é ensinado um CRUD nesses artigos, não poderia ser diferente aqui. Vou falar um pouco sobre os serviços primeiro.
Serviços
A primeira coisa que vemos de interessante é que ele oferece os serviços como a porta de entrada e saída de dados. Não há necessidade de fazer um controller para as tarefas mais comuns da API.
Vamos para um exemplo tirado da documentação oficial, com alguma modificação ditática:
Objetivo: Criar uma rota para persistir uma Task(tarefa).
Pois bem, então para isso precisamos primeiro criar sua entidade, com os seguintes atributos:
public class Task : Entity, IHasCreationTime
{
public string Title { get; set; }
public string Description { get; set; }
public DateTime CreationTime { get; set; }
public TaskState State { get; set; }
public Person AssignedUser { get; set; }
public Guid? AssignedUserId { get; set; }
public Task()
{
CreationTime = Clock.Now;
}
}O próximo passo é criar o método que será exposto, chamado de serviço. Mas para isso, antes precisamos definir o Dto.
Dto(data transfer object ou objeto de transferencia de dado) é um objeto cujo objetivo é apenas trafegar os dados. Uma coisa importante de entender é que criamos Dtos apenas para os objetos daquela determinada função. Podemos ter um Dto para criar Task e outro para recuperar todas as Tasks; cada um tem seus próprios atributos. Com isso, trazemos mais segurança expondo só o que realmente interessa.
O Dto para criar uma Task será o seguinte:
public class CreateTaskDto
{
public string Title { get; set; }
public string Description { get; set; }
}Note que na entidade há o atributo State e outro de AssignedUser. Esses atributos são da regra de negócio e o usuário não deve modifica-los.
E finalmente podemos criar o Serviço. Repare que ele herda de ApplicationService.
using System;public class TaskAppService : ApplicationService
{
private readonly IRepository<Task> _taskRepository;
public TaskAppService(IRepository<Task> taskRepository)
{
_taskRepository = taskRepository;
}public Task<TaskDto> CreateTask(CreateTaskDto input)
{
var task = Mapper<Task>(input);
//Note que aqui definimos o State padrão eAssignedUser é o próprio usuário
task.State = TaskState.New;
task.AssignedUserId = AbpSession.UserId;
// Fazemos a inserção utilizando o padrão Repository
_taskRepository.Insert(task); var taskDto = new TaskDto
{
Title = task.Title,
Description = task.Description,
State = task.State
};
return taskDto;
}
}
Repare que antes de retornar, transformamos o objeto em um outro Dto. Esse Dto contém o State, pois agora ele é relevante.
public class TaskDto
{
public string Title { get; set; }
public string Description { get; set; } public TaskState State { get; set; }
}
Com isso na aplicação e automagicamente irá surgir na esse metodo na api. Isso é chamado de Dynamic Web Api.
Podemos ver que deixamos o uso convencional de um controller apenas para casos que realmente sejam necessários.
Os serviços serão os mais utilizados, principalmente para criação de APIs.
Cache
Acessar o banco de dados para todas as operações pode ser custoso. Para isso a Cache serve perfeitamente.
Para isso foi implementada a classe CacheManager. O uso dela é extremamente simples como segue o exemplo abaixo:
public Item GetItem(int id)
{
//Try to get from cache
return _cacheManager
.GetCache("MyCache")
.Get(id.ToString(), () => GetFromDatabase(id)) as Item;
}O tempo de expiração padrão é de 60 minutos. Podendo ser configurado facilmente via propriedade.
cache.DefaultSlidingExpireTime = TimeSpan.FromHours(8); Beleza, mas tudo isso é para cache em memoria. Isso quer dizer que se quisermos escalar nossa aplicação, teremos problemas.
Para termos mais de uma aplicação rodando com cache, podemos usar o AbpRedis. A integração é muito fácil; basta subir o servidor redis e apontar a connection string para ele.
Está tudo bem explicadinho lá na documentação.
Traduções
Vale falar de traduções porque a biblioteca do ABP foi muito bem implementada. É tão fácil que já vem configurado e com algumas traduções. Basta você escolher o arquivo xml correspondente à sua tradução e colocar as chaves e o valores. Então o servidor vai empacotar essa tradução no primeiro request do frontend (uma SPA, por exemplo) e deixará disponivel como simples função.
No frontend basta você usar como:
var s1 = abp.localization.localize('NewTask', 'SimpleTaskSystem');E isso tudo já estará pronto se você escolher as opções de frontend que já estão implementadas: Angular, Vue, React ou server side.
Outras coisas
ABP é enorme. Ele oferece uma infinidade de coisas e sempre eu volto na documentação para ler um pouco mais do seu poder. Esses dias mesmo estavamos implementado um sistema de notificação e descobrimos mais tarde que o ABP já oferecia. Sorte nossa que não era exatamente o que precisavamos e não foi trabalho jogado fora.
Eu recomendo fortemente que se abra a documentação e leia como se não quisesse nada. Tem muita coisa lá que pode te surpreender, como me surpreendeu.
O Futuro
Abp é um framework que teve seu ínicio de desenvolvimento em 2013. Naquela época ainda não tinhamos um cenário forte de microserviços, banco de dados NoSql, entre outras coisas que estão na moda hoje em dia. Pensando nisso, a equipe de desenvolvimento do Asp.Net Boilerplate resolveu reescrever o projeto do zero e renomeou para somente Abp, devido ao termo boilerplate não se associar à um framework.
Não se preocupe, tudo que eu falei aqui continua sendo válido. Inclusive existe uma issue para que seja feito um guia de como migrar de um framework para outro. E o mais importante é que Asp.net Boilerplate continua recebendo atualiações também.
Conclusão
Depois de ter tentado desmistificar um pouco sobre a Microsoft e falar bem desse framework, eu sugiro fortemente em fazer uma pesquisa se caso irá começar um projeto novo utilizando Asp.net Core.
Hoje minha stack de desenvolvimento é Asp.net Boilerplate, MongoDb, VueJs, entre outras coisas. Todos trabalham em perfeita harmonia e raramente temos problemas.
E é isso galera, vou ir tentando melhorar esse artigo com novas seções sobre o framework!
