EF Core – Número sequencial customizável.

Criar um número sequencial é simples, mas e se ele tiver que começar de um determinado valor? E se precisar que seja incrementado de outra maneira? Aprenda como fazer!

Utilizar o EF Core facilita muito o processo de desenvolvimento, vamos aprender a configurar uma sequência customizada para evitar configurações extras no BD e deixar mais esta responsabilidade com nossa aplicação.

Neste exemplo vamos supor que possuímos uma classe Pedido e que possui uma propriedade código. Em código nós queremos que esse número inicie em 1000 no banco de dados e que seja incrementado automaticamente de 1 em 1.

O códigos a seguir explicam onde e como fazer esta simples configuração.

Primeiramente configuramos o contexto para criar uma sequencia chamada “MinhaSequencia” que inicia em 1000 e incrementa de 1 em 1.

Na configuração do mapeamento da entidade no EF basta apontar que aquela propriedade vai utilizar uma sequence conhecida:

Basta agora criar a Migration e rodar um “update-database” que estará tudo funcionando perfeitamente.


Vamos continuar a troca de experiências, deixe seu comentário abaixo. Se gostou e concorda com o artigo, compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis.

SOLID – OCP e Extension Methods

Extension Method é um recurso presente desde o C# 3.0 e que facilita bastante o uso do OCP – Open Closed Principle.

SOLID - Teoria e Prática

Os extension methods permitem que você adicione comportamentos em classes existentes sem precisar modificá-las. Os extension methods são um tipo especial de método estático, porém são chamados como se fossem métodos de instância na classe estendida.

Para o código escrito em .NET não há nenhuma diferença entre chamar um extension method ou os métodos realmente definidos em uma classe.

Como um recurso tão importante como este pode passar desconhecido por diversos desenvolvedores? É por este motivo que escrevi este artigo.

No SOLID os extension methods são perfeitos para aplicar OCP – Open Closed Principle de uma forma muito natural e proporcionando um código de baixo acoplamento.
Caso você não conheça todos os princípios do SOLID assista este tutorial completo.

Para demonstrar mais facilmente como utilizar os extension methods e aplicá-los ao OCP eu gravei um vídeo de 18 minutos onde rapidamente explico tudo.

* Assine meu canal no Youtube 🙂

O código fonte desta solução está disponível no GitHub

Referências


Se você estiver interessado em conhecer mais e aprender como desenvolver aplicações com uma arquitetura responsável utilizando DDD, TDD, BDD, aplicando os princípios SOLID, diversos Design Patterns e escrevendo testes de unidade conheça meus cursos:

Vamos continuar a troca de experiências, deixe seu comentário abaixo, se gostou e concorda com o artigo compartilhe com seus colegas para transmitirmos o conhecimento para o máximo de pessoas possíveis. ;)

SOLID – Teoria e Prática – Demo + Vídeo

SOLID – Teoria e Prática. É com certeza um dos temas mais debatidos no ramo de OOP, aprenda cada um dos princípios e como aplicá-los.

Este é um artigo complementar ao Orientação a Objeto – SOLID, neste primeiro artigo eu apresentei teoricamente o conceito do SOLID e seus benefícios.

SOLID – Teoria e Prática

Recapitulando

SOLID é um acrônimo dos cinco primeiros princípios da programação orientada a objetos e design de código identificados por Robert C. Martin (ou Uncle Bob) por volta do ano 2000. O acrônimo SOLID foi introduzido por Michael Feathers, após observar que os cinco princípios poderiam se encaixar nesta palavra.

Os princípios SOLID deveriam ser aplicados por qualquer desenvolvedor, porém pouquíssimos profissionais preocupam-se em utilizá-los, para obtermos todos os reais benefícios da OOP é necessário atender aos 5 princípios do SOLID.

Lembrando também que além destes 5 princípios Uncle Bob também mapeou 3 outros princípios sobre Coesão e mais outros 3 sobre Acoplamento. Utilize este link para conhecê-los também.

SLIDES

VÍDEO (1h00)

* Assine meu canal no Youtube 🙂

SOURCE

Para visualizar o fonte e realizar o download do projeto clique aqui (GitHub)

Referências

Vamos continuar enriquecendo o assunto, poste aqui sua opinião ou dúvida.

Tutorial ASP.NET MVC 5 + DDD + EF + AutoMapper + IoC + Dicas e Truques

Arquitetura de Sistemas Corporativos é um tema muito menos explorado do que ASP.NET MVC 5 e nem por isso é menos importante (na verdade é bem mais), neste vídeo tutorial eu mostrarei como criar uma arquitetura padrão DDD utilizando ASP.NET MVC 5.2, Entity Framework, AutoMapper, IoC com Ninject e muitas dicas para criar uma arquitetura modelo e totalmente responsável.

ASP.NET MVC 5 + DDD + EF + AutoMapper + IoC

Como poderão acompanhar nos slides e no vídeo ASP.NET MVC é apenas a ponta do iceberg em uma aplicação corporativa. Quando entramos no mundo real os exemplos dos artigos de sites e livros não nos atendem mais e é necessário buscar mais conhecimento para criar uma aplicação robusta, responsável, testável, escalável e de fácil manutenção.

O modelo DDD (Domain Driven Design) atende muito bem cenários de aplicações corporativas e eu utilizo muito em meus projetos profissionais e pessoais.

Neste vídeo tutorial você aprenderá

  • Criar uma solução padrão DDD
  • Separar a aplicação em camadas
  • Entidades de Domínio
  • Classes de Serviço
  • Criar Contratos (Interfaces)
  • Repositório Genérico
  • Repositório Especializado
  • Criar um Contexto do Entity Framework
  • Trabalhar com Migrations
  • Criar novas convenções do Entity Framework
  • Remover algumas convenções do Entity Framework
  • Sobrescrever o método SaveChanges para persistência de dados
  • Programar com CodeFirst
  • Utilizar FluentAPI para modelar tabelas
  • Criar Relacionamentos entre Entidades e refletindo nas tabelas do banco de dados.
  • Criar e utilizar a camada de Application
  • Trabalhar com classes genéricas de Entidades
  • Abstrair camadas com Injeção de Dependência (IoC)
  • Implementar o Ninject como container de IoC (DI)
  • Utilizar ViewModels
  • Utilizar DataAnnotations para validação de formulários
  • Mapear ViewModels x Entidade de Domínio com AutoMapper
  • Muitas dicas para acelerar sua produção

Este conteúdo é aplicado no meu curso de ASP.NET MVC 5 – Enterprise Applications com uma carga horária de 16 horas, com todo o embasamento teórico, técnico e prático, muitos outros patterns, testes, mocks, serviços REST, manipulação de filtros do ASP.NET MVC e etc são abordados no curso para uma preparação completa do futuro arquiteto desenvolvedor.

SLIDES

VÍDEO (3h00 de duração)

* Assine meu canal no Youtube 🙂

SOURCE

Para download do projeto clique aqui (logo será transferido para o GitHub)

Referências

Vamos continuar enriquecendo o assunto, poste aqui sua opinião ou dúvida 😉

Palestra sobre ASP.Net SignalR + Demos + Vídeo

Palestra sobre ASP.Net SignalR ministrada no Visual Studio Summit 2013.

ASP.Net SignalR

Desde que comecei a estudar ASP.Net SignalR me interessei muito e se tornou um dos meus assuntos favoritos, acompanhe aqui como foi minha palestra:

Vídeo da Palestra

Eu ainda não sou o bom palestrante que desejo ser, mas um dia chego lá 🙂

Slides

Demos (compatíveis com VS 2012)

*Jogo da velha original foi baixado aqui. Fiz melhorias, correções e complementos para demonstração.

Quer conhecer mais sobre ASP.Net SignalR? Leia o meu artigo aqui.

O Visual Studio Summit é um dos maiores eventos sobre desenvolvimento na plataforma Microsoft, assista todas palestras da edição 2013 aqui.

Deixe seu feedback logo abaixo 🙂
Abraços!

ASP.Net MVC – ViewData, ViewBag e TempData

ASP.Net MVC – ViewData, ViewBag e TempData entenda as diferenças.

Quando usar ViewData, ViewBag e TempData? Essa é uma das primeiras perguntas que qualquer desenvolvedor faz quando inicia nos aprendizados do ASP.Net MVC.

UPDATE – 13/06 – Adicionando detalhes/correções fornecidos pelo @vcavalcante

Vamos basear nossa explicação conforme a ilustração

ViewData, ViewBag, TempData

Similaridades entre ViewData e ViewBag

ViewData e ViewBag são similares nas seguintes características:

  • São utilizadas para persistir dados entre a Controller e a View correspondente.
  • A duração “tempo de vida” é apenas entre o envio através da Controller e a exibição na View, depois disso tornam-se nulas novamente.
  • No caso de um redirect se tornam nulas.

Diferenças entre ViewData e ViewBag

ViewData ViewBag
É um dicionário de objetos derivado de ViewDataDictionary e é acessível utilizando strings como chaves. É uma propriedade dinâmica baseada na funcionalidade “dynamic” do C# 4.0
Requer typecasting (conversão) quando associada a tipos complexos. Não necessida de conversão para tipos complexos.

Exemplos de aplicação

Controller

public class HomeController : Controller
{
    public ActionResult Index()
    {
        // Meu dado de tipo complexo
        var func = new Funcionario
                        {
                            Nome = "Eduardo Pires",
                            Idade = 31
                        };

        // Propriedades "Dinâmicas"
        ViewBag.Funcionario = func;

        // Modo tradicional
        ViewData["Funcionario"] = func;

        return View();
    }
}

View

@model ProjetoModelo.Models.Funcionario;

@{
    ViewBag.Title = "Exemplo ViewData ViewBag";

    // Necessita de TypeCasting
    var viewDataVariavel = ViewData["Funcionario"] as Funcionario;

    // Não necessita de TypeCasting
    var viewBagVariavel = ViewBag.Funcionario;
}

Resumindo, ViewData e ViewBag possuem a mesma proposta, porém o ViewBag está disponível a partir do ASP.Net MVC 3, enquanto o ViewData existe desde a primeira versão.

OBS: O ViewData é um wrapper, uma implementação do ViewBag, pois utiliza o ViewBag internamente, portanto:

// Criar o ViewBag:
ViewBag.Teste = "Eduardo";

// É o mesmo que criar um ViewData["Teste"],
// pois o ViewData é utilizado internamente. Se chamarmos:

var teste = ViewData["Teste"]; // Teremos teste = "Eduardo";

Por este motivo ViewData é mais rápido que o ViewBag, porém essa diferença de velocidade é mínima, não é necessário deixar de usar o ViewBag por este motivo.

Eu preferencialmente sempre utilizo ViewBag

TempData

  • TempData assemelha-se mais a uma sessão de servidor, porém de curta duração.
  • Possui um tempo de vida maior que o ViewBag e ViewData, o TempData perdura desde sua criação até que seja chamado, ou seja, quando houver um request da informação do TempData, ele se tornará nulo novamente.
  • Uma informação em TempData criada em um Controller persiste após um redirect entre actions (apenas um) e pode ser exibido em sequência em uma View (muito usado em tratamento de erros).
  • Caso não seja chamado o TempData pode manter o estado de seus dados até que a sessão do usuário se encerre.
  • É utilizado para compartilhar informações entre Controllers.
  • O TempData salva suas informações no SessionState do servidor.
  • Após a leitura os dados do TempData são marcados para deleção, ou seja, no final do request todos os dados marcados serão deletados.
  • É um benefício quando necessário transmitir um volume de informações entre as Controllers sem se preocupar em zerar os valores, pois o TempData automaticamente faz isso.

Exemplo de aplicação

Controller

public class HomeController : Controller
{
    [HttpPost]
    public ActionResult CriarFuncionario(Candidato cd)
    {
        // Meu dado de tipo complexo
        var func = new Funcionario
                        {
                            Nome = cd.Nome,
                            Idade = cd.Idade
                        };

        // Pertistir dados até o próximo request.
        TempData["Funcionario"] = func;

        // Redirect entre Controllers
        return RedirectToAction("CriarBeneficiosFuncionario");
    }

    [HttpGet]
    public ActionResult CriarBeneficiosFuncionario()
    {
        // Validando se está vazio
        if (TempData["Funcionario"] != null)
        {
            // Necessário TypeCasting para tipos complexos.
            var func = TempData["Funcionario"] as Funcionario;
        }

        return View();
    }
}

Neste exemplo pudermos entender que o propósito do TempData é compartilhar dados entre Controllers, portanto sua duração persiste até que a informação seja lida.
Outro detalhe é sempre checar se o TempData não está nulo.

Caso você queira manter o dado de um TempData mesmo após a leitura, basta chamar o método Keep(), assim o dado será persistido novamente até a próxima requisição.

// Mantendo o dado do TempData até a próxima leitura (requisição).
TempData.Keep("Funcionario");

// Removendo o dado do TempData desta e da próxima requisição.
TempData.Remove("Funcionario");

Recomenda-se utilizar sempre ViewBag e ViewData para transferência de dados entre Controller e View. O TempData em Views é recomendado no caso de um dado necessitar ser redirecionado entre Actions e posteriormente ser exibido numa View (ViewBag e ViewData são anulados em redirects).
Um caso comum dessa aplicação é no tratamento de erros, veja aqui um exemplo.

Espero ter esclarecido as diferenças e características de ViewData, ViewBag e TempData. Caso tenha alguma dúvida ou queira comentar algo, deixe seu recado logo abaixo 😉

Referências

SOLID – Open Closed Principle – OCP

Open Closed Principle, também conhecido como Princípio do Aberto Fechado.

OCP - Open Closed Principle

Este é o segundo princípio do SOLID e certamente o princípio mais polêmico, desconhecido e não utilizado.

Software entities (classes, modules, functions, etc.) should be open for 
extension, but closed for modification

Entidades de software (classes, módulos, funções, etc) devem estar abertas para extensão, mas fechadas para modificação.

Software é evolutivo, raramente um software é feito uma vez e nunca mais será modificado. Sendo assim onde esse princípio tenta chegar?

Extensibilidade

É uma das chaves da orientação a objetos, quando um novo comportamento ou funcionalidade precisar ser adicionado é esperado que as existentes sejam estendidas e e não alteradas, assim o código original permanece intacto e confiável enquanto as novas são implementadas através de extensibilidade. Criar código extensível é uma responsabilidade do desenvolvedor maduro, utilizar design duradouro para um software de boa qualidade e manutenibilidade.

Abstração

Quando aprendemos sobre orientação a objetos com certeza ouvimos sobre abstração, é ela que permite que este princípio funcione. Se um software possui abstrações bem definidas logo ele estará aberto para extensão.

Na prática

Vou usar um exemplo bem simples para podermos entender facilmente como funciona.
Observe esta classe:

public enum TipoDebito { ContaCorrente, Poupanca }

public class Debito
{
    public void Debitar(int valor, TipoDebito tipo)
    {
        if (tipo == TipoDebito.Poupanca)
        {
            // Debita Poupanca
        }
        if (tipo == TipoDebito.ContaCorrente)
        {
            // Debita ContaCorrente
        }
    }
}

É uma classe de débito em conta que valida o tipo da conta para aplicar a regra de negócio correta para conta corrente e para conta poupança. Agora vamos supor que surgiu um novo tipo de débito em conta (conta investimento), logo seria necessário modificar a classe.

Qual é o problema de um IF a mais?
Se modificarmos a classe colocando mais um IF de validação, além de ter que substituirmos esta classe na publicação da nova versão, corremos o risco de introduzir alguns bugs em uma classe que já estava funcionando.

Além de ter que testar todos os tipos de débito em conta, um bug introduzido nesta modificação não pararia apenas o débito em conta investimento mas poderia causar que todos os tipos de débitos parassem de funcionar.

Não queremos isso certo? Na verdade queremos ter o mínimo de trabalho possível e maior garantia de qualidade.

Como deveria ser?

Vamos para um exemplo de um código usando abstração para gerar extensibilidade:

public abstract class Debito
{
    public abstract void Debitar(int valor);
}

public class DebitoContaCorrente : Debito
{
    public override void Debitar(int valor)
    {
        // Debita Conta Corrente
    }
}

public class DebitoContaPoupanca : Debito
{
    public override void Debitar(int valor)
    {
        // Debita Conta Poupança
    }
}

public class DebitoContaInvestimento : Debito
{
    public override void Debitar(int valor)
    {
        // Debita Conta Investimento
    }
}

Veja que possuímos agora uma abstração bem definida, onde todas as extensões implementam suas próprias regras de negócio sem necessidade de modificar uma funcionalidade devido mudança ou inclusão de outra.

O tipo de débito em conta de investimento foi implementado sem modificar nada, usando apenas a extensão. Além de tudo o código está muito mais bonito, entendível e fácil para aplicar cobertura de testes de unidade. Vale mencionar que também está de acordo com o primeiro princípio do SOLID o SRP

Conclusão

Este princípio nos atenta para um melhor design, tornando o software mais extensível e facilitando sua evolução sem afetar a qualidade do que já está desenvolvido.

Para o uso do Open Closed Principle é muito comum utilizarmos o Strategy Pattern do GoF, prometo explicá-lo em outro momento, apenas para não tornar este exemplo muito complexo.

Referências

SOLID – Single Responsibility Principle – SRP

Single Responsibility Principle, também conhecido como Princípio da Responsabilidade Única.

SOLID - Single Responsibility Principle - SRP

Este é o primeiro princípio do SOLID, um dos mais fáceis de entender e de aplicar.

"A class should have one, and only one, reason to change"

“Uma classe deve ter um, e apenas um, motivo para ser modificada”

Se uma classe só deve ter um motivo para ser modificada, certamente ela só deve ter uma única responsabilidade, logo:

Cada responsabilidade deve ser uma classe, porque uma responsabilidade é um eixo de mudança.

Veja esta classe:

public class DebitoContaCorrente
{
    public void ValidarSaldo(int valor) { }

    public void DebitarConta(int valor) { }

    public void EmitirComprovante() { }
}

O que esta classe faz?

Esta classe valida saldo em conta e debita valor da conta e emite comprovante.

Esta classe possui três responsabilidades, ou seja, ela tem três razões para ser modificada, problemas a vista, vamos imaginar que por algum motivo a regra de negócio da emissão de comprovante mudou, logo para aplicar a nova regra seria necessário modificar a classe DebitoContaCorrente.

Se por um acaso na modificação da classe algum bug não identificado foi para a produção não apenas a emissão de comprovante, mas sim todas as funcionalidades da classe poderiam estar comprometidas. O sistema deixaria de fazer o débito devido um problema com o comprovante.

Esse é apenas um exemplo de como o acoplamento pode trazer problemas, testes de unidade seriam muito mais complexos de serem desenvolvidos (e menos eficazes).
Ao modificar esta classe vários testes de integração necessitariam ser executados para garantir que uma funcionalidade não comprometeu as demais.

Alguns benefícios do Single Responsibility Principle:

  • Complexidade do código reduzida, mais explícita e direta;
  • Facilitação da legibilidade;
  • Redução de acoplamento;
  • Código limpo e testável;
  • Facilidade de evolução.

Como deveria ser?

Veja como a classe poderia ficar após um refactoring de aplicação do Single Responsibility Principle:

public class DebitoContaCorrente
{
    public void DebitarConta(int valor) { }
}

public class SaldoContaCorrente
{
    public void ValidarSaldo(int valor) { }
}

public class ComprovanteContaCorrente
{
    public void EmitirComprovante() { }
}

Cada classe com sua responsabilidade.
No início isso pode parecer exagero, mas não é, isto é uma promoção da qualidade do código e uma ótima maneira de obter os benefícios citados acima.

Conclusão

O Single Responsibility Principle é um dos mais importantes princípios do SOLID, deve ser aplicado para obtermos classes mais coesas e de baixo acoplamento.

Este é o tipo de princípio que todo código orientado a objetos deveria possuir.
Portanto antes de construir aquela classe que cadastra o usuário e envia o e-mail, lembre-se deste princípio.

Referências

Erro do EF Migrations ao atualizar o Database no SQL Azure

Ao executar o comando update-database via Migrations do EF CodeFirst para atualizar um database hospedado no SQL Azure você pode receber uma mensagem de erro:

Tables without a clustered index are not supported in this version of SQL Server. Please create a clustered index and try again.

Pesquisando sobre o erro descobri que é um bug já reportado do EF 6 Alfa 3.
O motivo apresentado por Andrew Peters (EF Developer) foi:

This causes Migrations not to work on Azure because the history table needs at least one clustered PK

Como resolver:

1- Atualize a versão da biblioteca do EF 6 (a correção foi disponibilizada em 07/03/2013).

2 -Caso não seja possível a atualização da biblioteca, existe um workaround:

Crie uma classe de custom migration SQL generator

using System.Data.Entity.Migrations.Model;
using System.Data.Entity.Migrations.Sql;

public class AzureSqlGenerator : SqlServerMigrationSqlGenerator
{
    protected override void Generate(CreateTableOperation createTableOperation)
    {
        if ((createTableOperation.PrimaryKey != null)
            && !createTableOperation.PrimaryKey.IsClustered)
        {
            createTableOperation.PrimaryKey.IsClustered = true;
        }

        base.Generate(createTableOperation);
    }
}

E registre a sua custom generator no arquivo Configuration.cs da pasta Migrations

internal sealed class Configuration : DbMigrationsConfiguration<MyContext>
{
    public Configuration()
    {
        AutomaticMigrationsEnabled = true;

        // Esta linha abaixo:
        SetSqlGenerator("System.Data.SqlClient", new AzureSqlGenerator());
    }

    protected override void Seed(MyContext context)
    {
    }
}

Pronto!
Pode rodar novamente o comando update-database que o problema estará resolvido.

Até a próxima 😉

Orientação a Objeto – SOLID

SOLID é um acrônimo dos cinco primeiros princípios da programação orientada a objetos e design de código identificados por Robert C. Martin (ou Uncle Bob) por volta do ano 2000. O acrônimo SOLID foi introduzido por Michael Feathers, após observar que os cinco princípios poderiam se encaixar nesta palavra.

São eles:

Letra Sigla Nome Definição
S  SRP Principio da Responsabilidade Única Uma classe deve ter um, e somente um, motivo para mudar.
O  OCP Princípio Aberto-Fechado Você deve ser capaz de estender um comportamento de uma classe, sem modificá-lo.
L  LSP Princípio da Substituição de Liskov As classes base devem ser substituíveis por suas classes derivadas.
I  ISP Princípio da Segregação da Interface Muitas interfaces específicas são melhores do que uma interface única.
D  DIP Princípio da inversão da dependência Dependa de uma abstração e não de uma implementação.

Os princípios SOLID devem ser aplicados para se obter os benefícios da orientação a objetos, tais como:

  • Seja fácil de se manter, adaptar e se ajustar às alterações de escopo;
  • Seja testável e de fácil entendimento;
  • Seja extensível para alterações com o menor esforço necessário;
  • Que forneça o máximo de reaproveitamento;
  • Que permaneça o máximo de tempo possível em utilização.

Utilizando os princípios SOLID é possível evitar problemas muito comuns:

  • Dificuldade na testabilidade / criação de testes de unidade;
  • Código macarrônico, sem estrutura ou padrão;
  • Dificuldades de isolar funcionalidades;
  • Duplicação de código, uma alteração precisa ser feita em N pontos;
  • Fragilidade, o código quebra facilmente em vários pontos após alguma mudança.

Os princípios SOLID deveriam ser aplicados por qualquer desenvolvedor maduro, porém pouquíssimos profissionais preocupam-se em utilizá-los, sugiro que crie um sistema simples e utilize estes princípios para treinar, será uma experiência gratificante.

Este é apenas o artigo introdutório sobre SOLID, nos próximos abordarei cada princípio em um artigo separadamente, explicando e demonstrando com código e exemplos a proposta de cada um, continue acompanhando 😉

Referências: