fbpx
Oragon.Spring no ASP.NET Core – Get Started Tutorial (PT-BR)
Publicado em: domingo, 27 de jan de 2019
Categorias: .NET | Arquitetura | Novidades

Quem trabalhou de perto nos meus projetos sabe que tenho uma opinião bem radical a respeito da maioria dos frameworks de injeção de dependência. Aliás, compartilhando contigo minha opinião: Eles fazem injeção de dependência, mas pouco sobre IoC, e podem, diversas vezes ser encarados meramente como Service Locators, o que na minha opinião deixa pobre qualquer implementação que queira se fundamentar em IoC e DI.

A origem

Eu já disse o que me levou a portar o Spring.NET para .NET Standard, eu fiz isso faz um tempinho, agora já tenho projetos em produção usando. Agora que estou começando um novo projeto do zero, acho que esse é um bom momento para começar uma série de posts sobre o tema. A propósito Dependency Injection é um tema que me interessa já faz muito tempo, pelo menos 10 anos, e por isso gosto de tocar nesse assunto com certa freqüência, e você pode achar diversos posts no tópico #dependency-injection.

Propósito desse post

Esse post tem o propósito de apresentar o mais básico: o setup de um projeto ASP.NET Core 2.2 com .NET Core, rodando em containers, no Linux.

Criando o projeto

O primeiro passo é criar um projeto do zero, fica mais fácil explicar assim, pois um projeto simples torna todo o fluxo mais compreensível.

Adicionando dependências

Agora que o projeto está criado, devemos adicionar as dependências Oragon.Spring. Com um único pacote nuget podemos fazer isso:

Adicione o pacote nuget Oragon.Spring.Extensions.DependencyInjection. Ele traz consigo Oragon.Spring.Core (mas não traz Oragon.Spring.AOP fique atento a isso). Nesse tutorial aqui, não será necessário, mas como minha ideia é usar esse post como referência na série, lá na frente vamos precisar desse pacote, quando falarmos de AOP.

Pronto, até aqui temos um novo projeto, com o Oragon.Spring, falta agora criar um arquivo de configuração e alterar alguns detalhes no Startup.cs. Vamos lá?

No Startup.cs vamos alterar o método ConfigureServices:

public IServiceProvider ConfigureServices(IServiceCollection services)
{
    services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2);

    return services.WithSpring(
        $"assembly://Oragon.Spring.GetStarted/Oragon.Spring.GetStarted/Container.config.xml"
    );
}

Note que a versão default do método ConfigureServices tem a assinatura void ConfigureServices(IServiceCollection services) enquanto a nossa é ligeiramente diferente e retorna um IServiceProvider. Nesse exemplo estou usando o arquivo de configuração como embedded resource. Veremos isso a seguir.

A sintaxe para é de formação de nome é a seguinte:

$”assembly://[AssemblyName]/[Namespace]/[FileName]”

A parte de namespace segue o mesmo princípio que o visual studio usa para criar arquivos nos devidos namespaces (usando o namespace padrão do projeto e suas pastas).

O próximo elemento que você precisa criar é o arquivo XML do Spring, eu criei com o nome de Container.config.xml. A primeira versão dele, vazio é a seguinte.

<?xml version="1.0" encoding="utf-8" ?>
<objects
    xmlns="http://www.springframework.net"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:aop="http://www.springframework.net/aop"
>

</objects>

Esse é o arquivo em que vamos configurar o container IoC. O Oragon.Spring, nem o Sprinng.net não exigem a utilização de embedded resources, no entanto, como na configuração desse exemplo será necessário. A única demanda para funcionar é que seja coerente. (se configurar como embedded resource, coloque-o como embedded resource, se quer carregar a partir do disco, configure corretamente o path para isso).

 

Checkpoint 1

Nesse momento se você fez tudo certo, teu projeto vai rodar e vai exibir a rota default (api/values) sem apresentar nenhum problema. O Oragon.Spring já está sendo carregado, mas não tem o que entregar ainda, pois sua configuração está vazia e não há ninguém demandando nada dele. Mas a partir de agora vamos mudar isso e integrá-lo ao seu código, mas antes disso:

Teste rodando com os diversos profiles:

  • Docker
  • Oragon.Spring.GetStarted
  • IIS Express

Nesse ponto, todos os profiles devem funcionar perfeitamente.

Caso apareça algum erro, revise todos os passos anteriores, você deve ter pulado ou ignorado alguma coisa.

Configurando seu Visual Studio

Até o momento teu projeto está pronto, mas falta configurar seu visual studio. Essa configuração é super simples, você vai colocar 3 arquivos XSD que no path de Schemas do Visual Studio, é o suficiente para habilitar o intellisense do XML de configuração do Spring. 

Fique atento e não pule essa etapa. Se você não tiver os XSD no teu visual studio, você levará de 4 a 7 vezes mais tempo para se adaptar. E é provável que você abandone a ideia de testar exatamente nessa parte.

A forma mais fácil de descobrir o path é achar a instalação do visual studio que estiver rodando seu projeto. Nem precisa fechar a IDE, basta achar o path. 

Seu Visual Studio roda sob a pasta ./Common7/IDE, volte 2 níveis e você já se depara com a pasta XML, dentro dela há uma pasta Schemas. Como mostra a imagem abaixo:

Copie os arquivos (estão no repositório do projeto ou faça download aqui). 

Uma vez copiados os arquivos, está tudo pronto, e agora é hora de testar:

Vá no meio do arquivo (entre a tag <objects> e </objects>) e digite “<” (sinal de menor).

Se você fez tudo certinho, você já verá o intelisense trabalhando por você:

Em 2010 eu fiz um vídeo para mostrar isso na prática, funcionando:

Esse passo não é necessário, nem requisito para nada funcionar, exceto o intellisense. Porém, sem ele, a chance de você ficar perdido(a) é muito grande.

Dando vida à injeção de dependência.

Agora é hora de da vida a isso tudo, seu projeto está configurado, seu ambiente está configurado.

Eu criei uma classe OragonSpringExample, um POCO simples, apenas para demonstrar algumas capacidades bem básicas. 

public class OragonSpringExample
{
    public string StringExample { get; set; }

    public int IntExample { get; set; }

    public DateTime? ReveillonTime { get; set; }

    public DateTime CurrentTime { get; set; }

    public bool BooleanProperty { get; set; }

    public List<OragonSpringExample> ChildList { get; set; }

    public string FillOnConstructor { get; }

    public OragonSpringExample(string constructorParameter)
    {
        this.FillOnConstructor = constructorParameter;
    }
}

Coloquei algumas datas, strings, números, booleans, listas, enfim, não há limitação pelo aspecto de factory do spring. 

Nosso ValuesController, mudou um pouco, afinal queremos mostrar o resultado no browser!

[Route("api/[controller]")]
[ApiController]
public class ValuesController : ControllerBase
{
	[HttpGet]
	public ActionResult<OragonSpringExample> Get([FromServices] OragonSpringExample oragonSpringExample)
	{
		return oragonSpringExample;
	}
}

E por fim, nosso xml de configuração ficou assim:

<?xml version="1.0" encoding="utf-8" ?>
<objects
    xmlns="http://www.springframework.net"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:aop="http://www.springframework.net/aop"
>

  <object name="OragonSpringExample" type="Oragon.Spring.GetStarted.Model.OragonSpringExample, Oragon.Spring.GetStarted">

    <constructor-arg  name="constructorParameter" value="On Constructor Too"/>

    <property name="StringExample" value="aa" />

    <property name="IntExample" value="7" />

    <property name="ReveillonTime" expression="date('2017/12/31')" />

    <property name="CurrentTime" expression="DateTime.Now" />

    <property name="BooleanProperty" value="true"/>

    <property name="ChildList">

      <list element-type="Oragon.Spring.GetStarted.Model.OragonSpringExample, Oragon.Spring.GetStarted">

        <object name="OragonSpringExample" type="Oragon.Spring.GetStarted.Model.OragonSpringExample, Oragon.Spring.GetStarted">

          <constructor-arg  name="constructorParameter" value="Child - Composite"/>

        </object>

      </list>

    </property>

  </object>

</objects>

Agora executando como um container docker, vemos o seguinte resultado no browser!

{
  "stringExample": "aa",
  "intExample": 7,
  "reveillonTime": "2017-12-31T00:00:00",
  "currentTime": "2019-01-27T03:03:51.9106723+00:00",
  "booleanProperty": true,
  "childList": [
    {
      "stringExample": null,
      "intExample": 0,
      "reveillonTime": null,
      "currentTime": "0001-01-01T00:00:00",
      "booleanProperty": false,
      "childList": null,
      "fillOnConstructor": "Child - Composite"
    }
  ],
  "fillOnConstructor": "On Constructor Too"
}

Conclusão

Bom, chegamos ao fim! 

Esse é um hello world ASP.NET Core com o Oragon Spring, fork do Spring .NET portado para .NET Standard.

Limitações: Container são tipos especiais do qual não podem ser configurados no spring. O pipeline do .NET Core complica muito a gestão de dependência das outras dependências ao redor dos Controllers, portanto conseguimos resulta dependências dos controllers, mas não os controllers em si.

Outro ponto é que como o resultado do Extension Method ser um IServiceProvider, ele já dá a pista de que consegue rodar em modo console, integrado ao ASP.NET Core. Mas pode trabalhar isolado e independente, é uma questão de gosto. Nos meus projetos eu sempre trabalho integrado para não perder características fundamentais, como os arquivos de configuração do projeto.

Exemplo no github

O projeto está no repositório do github https://github.com/Oragon/Oragon.Spring.GetStarted.

Fique de olho nos branches. O branch para esse post é esse aqui: https://github.com/Oragon/Oragon.Spring.GetStarted/tree/01-GetStarted

 

O Cloud Native .NET é meu principal projeto.

Onde empenho energia para ajudar, acompanhar, direcionar Desenvolvedores, Líderes Técnicos e jovens Arquitetos na jornada Cloud Native.

Conduzo entregando a maior e mais completa stack de tecnologias do mercado.

Ao trabalhar com desenvolvedores experientes, eu consigo usar seu aprendizado com .NET, banco de dados, e arquitetura para encurtar a jornada.

Ao restringir à desenvolvedores .NET eu consigo usar do contexto de tecnologias e problemas do seu dia-a-dia, coisas que você conhece hoje, como WCF, WebForms, IIS e MVC, por exemplo, para mostrar a comparação entre o que você conhece e o que está sendo apresentado.

É assim que construímos fundamentos sólidos, digerindo a complexidade com didática, tornando o complexo, simples.

É assim que conseguimos tornar uma jornada densa, em um pacote de ~4 meses.

Eu não acredito que um desenvolvedor possa entender uma tecnologia sem compreender seus fundamentos. Ele no máximo consegue ser produtivo, mas isso não faz desse desenvolvedor um bom tomador de decisões técnicas.

É preciso entender os fundamentos para conseguir tomar boas decisões.

0 comentários

Enviar um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

[docker de a a z]

Lives

Fique de olho nas lives

Fique de olho nas lives no meu canal do Youtube, no Canal .NET e nos Grupos do Facebook e Instagram.

Aceleradores

Existem diversas formas de viabilizar o suporte ao teu projeto. Seja com os treinamentos, consultoria, mentorias em grupo.