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 😉

ASP.NET Identity – Customizando o cadastro de usuários

Com o lançamento do ASP.NET MVC 5 um novo modelo de autenticação e autorização foi disponibilizado, o ASP.NET Identity, uma solução muito mais aberta e granular, acompanhe aqui como efetuar algumas customizações.

O ASP.NET Identity pode ser configurado no momento da criação da aplicação web, onde algumas opções são disponibilizadas para sua utilização, neste exemplo utilizarei o modelo de Individual User Accounts (modelo padrão).

ASP.NET Identity

O template de projeto que o Visual Studio disponibiliza na criação da aplicação ASP.NET MVC contempla uma implementação do ASP.NET Identity da qual já é possivel cadastrar-se como usuário. Ao executarmos o projeto pela primeira vez e clicar no link Register no topo da aplicação, será exibida a View de registro.

ASP.NET Identity

Até este ponto mais fácil seria impossível certo?
Suponha que o seu cadastro necessite de mais algumas informações como:

  • Nome
  • Sobrenome
  • E-mail

O ASP.NET Identity expõe um conjunto de classes de forma que fica muito fácil realizar qualquer tipo de customização. Mãos à obra.

Passo 1 – Customizar a classe de usuário

Localize e abra o arquivo IdentityModels.cs na pasta Models do seu projeto ASP.NET MVC. O código original será este:

namespace DemoIdentity.Models
{
    public class ApplicationUser : IdentityUser
    {
    }

    public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
    {
        public ApplicationDbContext()
            : base("DefaultConnection")
        {
        }
    }
}

Observe que existem duas classes nesse arquivo (depois refatoramos) a classe ApplicationUser é sua classe de usuário, note que ela não possui propriedade nenhuma apenas herda de IdentityUser, pois é esta classe que possui as propriedades de usuário, a classe ApplicationUser está ali disponível justamente para a customização.

Abaixo o código após a customização

namespace DemoIdentity.Models
{
    public class ApplicationUser : IdentityUser
    {
        public string Nome { get; set; }

        public string Sobrenome { get; set; }

        public string Email { get; set; }
    }

    public class ApplicationDbContext : IdentityDbContext<ApplicationUser>
    {
        public ApplicationDbContext()
            : base("DefaultConnection")
        {
        }
    }
}

Passo 2 – Customizar a ViewModel

Neste projeto está sendo utilizado o padrão ViewModel, isso significa que a View de registro é baseada nesta ViewModel para exibir as informações em tela.

Localize e abra o arquivo AccountViewModels.cs na pasta Models, originalmente existem quatro classes neste mesmo arquivo (mais um item para refatorar). Encontre a classe RegisterViewModel:

public class RegisterViewModel
{
    [Required]
    [Display(Name = "User name")]
    public string UserName { get; set; }

    [Required]
    [StringLength(100, ErrorMessage = "The {0} must be at least {2} characters long.", MinimumLength = 6)]
    [DataType(DataType.Password)]
    [Display(Name = "Password")]
    public string Password { get; set; }

    [DataType(DataType.Password)]
    [Display(Name = "Confirm password")]
    [Compare("Password", ErrorMessage = "The password and confirmation password do not match.")]
    public string ConfirmPassword { get; set; }
}

A mesma classe agora após a customização:

public class RegisterViewModel
{
    [Required]
    [Display(Name = "User name")]
    public string UserName { get; set; }

    [Required]
    public string Nome { get; set; }

    [Required]
    public string Sobrenome { get; set; }

    [Required]
    [Display(Name = "E-mail")]
    [EmailAddress]
    public string Email { get; set; }

    [Required]
    [StringLength(100, ErrorMessage = "The {0} must be at least {2} characters long.", MinimumLength = 6)]
    [DataType(DataType.Password)]
    [Display(Name = "Password")]
    public string Password { get; set; }

    [DataType(DataType.Password)]
    [Display(Name = "Confirm password")]
    [Compare("Password", ErrorMessage = "The password and confirmation password do not match.")]
    public string ConfirmPassword { get; set; }
}

Note que fiz uso de alguns DataAnnotations para configurar que os campos sejam requeridos e para ocorrer a validação de formato de email durante o input dos dados.

Passo 3 – Customizar a View

Agora para preencher com dados as novas propriedades da ViewModel será necessário customizar a View.

Localize e abra o arquivo Register.cshtml na pasta Views > Account.
Note que a View faz uso da ViewModel que acabamos de customizar

@model DemoIdentity.Models.RegisterViewModel

O resultado final da View será esse:

@model DemoIdentity.Models.RegisterViewModel
@{
    ViewBag.Title = "Register";
}

<h2>@ViewBag.Title.</h2>

@using (Html.BeginForm("Register", "Account", FormMethod.Post, new { @class = "form-horizontal", role = "form" }))
{
    @Html.AntiForgeryToken()
    <h4>Create a new account.</h4>
    <hr />
    @Html.ValidationSummary()
    <div class="form-group">
        @Html.LabelFor(m => m.UserName, new { @class = "col-md-2 control-label" })
        <div class="col-md-10">
            @Html.TextBoxFor(m => m.UserName, new { @class = "form-control" })
        </div>
    </div>

    <div class="form-group">
        @Html.LabelFor(m => m.Nome, new { @class = "col-md-2 control-label" })
        <div class="col-md-10">
            @Html.TextBoxFor(m => m.Nome, new { @class = "form-control" })
        </div>
    </div>

    <div class="form-group">
        @Html.LabelFor(m => m.Sobrenome, new { @class = "col-md-2 control-label" })
        <div class="col-md-10">
            @Html.TextBoxFor(m => m.Sobrenome, new { @class = "form-control" })
        </div>
    </div>

    <div class="form-group">
        @Html.LabelFor(m => m.Email, new { @class = "col-md-2 control-label" })
        <div class="col-md-10">
            @Html.TextBoxFor(m => m.Email, new { @class = "form-control" })
        </div>
    </div>

    <div class="form-group">
        @Html.LabelFor(m => m.Password, new { @class = "col-md-2 control-label" })
        <div class="col-md-10">
            @Html.PasswordFor(m => m.Password, new { @class = "form-control" })
        </div>
    </div>
    <div class="form-group">
        @Html.LabelFor(m => m.ConfirmPassword, new { @class = "col-md-2 control-label" })
        <div class="col-md-10">
            @Html.PasswordFor(m => m.ConfirmPassword, new { @class = "form-control" })
        </div>
    </div>
    <div class="form-group">
        <div class="col-md-offset-2 col-md-10">
            <input type="submit" class="btn btn-default" value="Register" />
        </div>
    </div>
}

@section Scripts {
    @Scripts.Render("~/bundles/jqueryval")
}

Execute a aplicação para validar o resultado:

ASP.NET Identity

Passo 4 – Customizar a Controller

Este é o passo final, apesar da navegação estar pronta, a Controller ainda não está apta a receber as novas propriedades customizadas e realizar a gravação no banco.

Localize e abra o arquivo AccountController.cs na pasta Controllers
Identifique a Action de registro, o código original será este:

[HttpPost]
[AllowAnonymous]
[ValidateAntiForgeryToken]
public async Task<ActionResult> Register(RegisterViewModel model)
{
    if (ModelState.IsValid)
    {
        var user = new ApplicationUser() { UserName = model.UserName };
        var result = await UserManager.CreateAsync(user, model.Password);
        if (result.Succeeded)
        {
            await SignInAsync(user, isPersistent: false);
            return RedirectToAction("Index", "Home");
        }
        else
        {
            AddErrors(result);
        }
    }

    return View(model);
}

Após a customização o resultado deverá ser este:

public async Task<ActionResult> Register(RegisterViewModel model)
{
    if (ModelState.IsValid)
    {
        var user = new ApplicationUser()
        {
            UserName = model.UserName,
            Nome = model.Nome,
            Sobrenome = model.Sobrenome,
            Email = model.Email
        };

        var result = await UserManager.CreateAsync(user, model.Password);
        if (result.Succeeded)
        {
            await SignInAsync(user, isPersistent: false);
            return RedirectToAction("Index", "Home");
        }
        else
        {
            AddErrors(result);
        }
    }

    return View(model);
}

Note que esta Action recebe o objeto RegisterViewModel como parâmetro, foi necessário apenas inserir as novas propriedades do objeto ApplicationUser que receberão as informações que vieram da ViewModel.

Sua customização está finalizada, execute a aplicação, registre um usuário e confira o resultado.

Observações:

  • O primeiro cadastro pode demorar um pouco, pois o mecanismo do Code First está criando o banco de dados e as tabelas necessárias para o ASP.NET Identity operar.
  • Faça testes no formulário, por ex, deixar algum campo em branco ou usar um e-mail em formato inválido.

Após registrar o usuário pela aplicação, você pode conferir o resultado da criação do banco de dados através do painel SQL Server Object Explorer do Visual Studio:

ASP.NET Identity

Vimos que é muito fácil realizar uma customização de um controle de acesso pelo ASP.NET Identity, caso queira criar mais campos basta seguir o mesmo roteiro.

Referências

Em breve publicarei mais artigos de customização do ASP.NET Identity, com técnicas mais avançadas e refatoração do projeto original.

Ficou com dúvidas? Quer compartilhar conosco alguma experiência? Utilize os comentários abaixo 😉

Até a próxima.

ASP.Net MVC – AutoMapper e View Models

O AutoMapper é uma biblioteca pequena e simples construída para resolver um problema aparentemente complexo, que é livrar-se de um código que mapeou um objeto para outro. Este tipo de problema é muito comum e relativamente trabalhoso de resolver,  a ferramenta AutoMapper atua nesse cenário de forma simples e elegante.

ASP.Net MVC AutoMapper

No artigo anterior foi abordado o padrão View Model no ASP.Net MVC, esse padrão ajuda a organizar o código, pois divide as responsabilidades entre as Models de domínio e as Models que atendem Views, evitando que as Models de domínio sejam alteradas e poluídas com dados desnecessários ao domínio.

A primeira técnica de trabalhar com View Models foi abordada no artigo anterior.
A técnica abordada neste artigo é mais complexa e necessita de um mapeamento entre objetos que é feito com a ajuda da ferramenta AutoMapper.

No livro Padrões de Arquitetura de Aplicações Corporativas, Martin Fowler descreve um padrão base chamado Mapper. O AutoMapper foi desenvolvido por Jimmy Bogard, um dos autores do livro ASP.Net MVC 4 in Action.

Mapeando uma Model de domínio para uma View Model

O cenário deste exemplo é baseado em um sistema muito simples que consulta os dados de um cliente cadastrado e informa um número da sorte gerado randomicamente para este cliente.

Neste cenário possuímos a Model de domínio (cliente).

using System;

namespace MvcMapping.Models
{
    public class Cliente
    {
        public string Nome { get; set; }
        public string Sobrenome { get; set; }
        public DateTime DataNascimento { get; set; }
        public bool Ativo { get; set; }
    }
}

Note que não existe referência ao dado de número da sorte, pois ele é exibido apenas na View e não é armazenado com os dados de cliente, logo torna-se desnecessário fazer parte da modelagem da Model.

Na técnica apresentada anteriormente a solução seria criar uma View Model com uma propriedade do tipo cliente e complementar com dados adicionais a serem exibidos na View.
Este artigo irá abordar outra técnica que consiste em criar uma classe com a mesma estrutura de cliente e mais os novos dados adicionais, chamaremos ela de ClienteViewModel e estará disponível em uma pasta raiz do projeto MVC chamada ViewModels.

using System;
using System.ComponentModel.DataAnnotations;

namespace MvcMapping.ViewModels
{
    public class ClienteViewModel
    {

        [Required(ErrorMessage = "Preencher campo Nome")]
        public string Nome { get; set; }

        public string Sobrenome { get; set; }

        [Required(ErrorMessage = "Preencher campo Data de Nascimento")]
        [Display(Name = "Data de Nascimento")]
        [DisplayFormat(ApplyFormatInEditMode = true, DataFormatString = "{0:yyyy-MM-dd}")]
        [DataType(DataType.Date, ErrorMessage="Data em formato inválido")]
        public DateTime DataNascimento { get; set; }

        public bool Ativo { get; set; }

        public int NumeroDaSorte { get; set; }
    }
}

Na classe ClienteViewModel possuímos a mesma estrutura de clientes, mais o dado adicional de número da sorte e os DataAnnotations para validação de formulário.

Até este momento já é possível listar três benefícios imediatos:

  • A Model de domínio não precisou ser modificada sem necessidade.
  • A Model de domínio não está poluída com DataAnnotations de validação de formulário.
  • A manutenção destas classes torna-se muito mais fácil, uma vez que a Model de domínio não está amarrada às características de uma View.

Após a separação das responsabilidades temos uma Model e uma View Model, ambas representando a entidade cliente, agora é necessário mapear um objeto ao outro para que a ClienteController receba a Model cliente e responda para View uma ClienteViewModel (e vice-versa), esse trabalho é executado pelo AutoMapper.

Configurando o AutoMapper no projeto ASP.Net MVC

Primeiramente é necessário configurar as referências das bibliotecas do AutoMapper e isto pode ser feito facilmente com o NuGet

PM> Install-Package AutoMapper

No projeto MVC crie uma pasta vazia chamada Mappers, dentro desta pasta será necessário criar uma classe que servirá de configuração dos profiles de mapeamento (Model > View Model) e (View Model > Model), esses profiles de mapeamento foram separados em dois arquivos, confira como abaixo como criar cada um deles.

Classe AutoMapperConfig

using AutoMapper;

namespace MvcMapping.Mappers
{
    public class AutoMapperConfig
    {
        public static void RegisterMappings()
        {
            Mapper.Initialize(x =>
            {
                x.AddProfile<DomainToViewModelMappingProfile>();
                x.AddProfile<ViewModelToDomainMappingProfile>();
            });
        }
    }
}

Classe DomainToViewModelMappingProfile

[UPDATE – 12/2015]Não é mais possível fazer o override do ProfileName nas novas versões do AutoMapper. Basta não sobrescrever esta property

using AutoMapper;
using MvcMapping.Models;
using MvcMapping.ViewModels;

namespace MvcMapping.Mappers
{
    public class DomainToViewModelMappingProfile : Profile
    {
        // Não realizar este override na versão 4.x e superiores
        public override string ProfileName
        {
            get { return "DomainToViewModelMappings"; }
        }

        protected override void Configure()
        {
            Mapper.CreateMap<Cliente, ClienteViewModel>();
        }
    }
}

Classe ViewModelToDomainMappingProfile

using AutoMapper;
using MvcMapping.Models;
using MvcMapping.ViewModels;

namespace MvcMapping.Mappers
{
    public class ViewModelToDomainMappingProfile : Profile
    {
        // Não realizar este override na versão 4.x e superiores
        public override string ProfileName
        {
            get { return "ViewModelToDomainMappings"; }
        }

        protected override void Configure()
        {
            Mapper.CreateMap<ClienteViewModel, Cliente>();
        }
    }
}

Esta é a estrutura necessária para configurar o AutoMapper de forma a utilizar o mínimo possível de código de mapeamento em outras classes da aplicação.

  • AutoMapperConfig > Inicializa os profiles de mapeamento (Model > View Model) e (ViewModel > Model).
  • DomainToViewModelMappingProfile > Profile de mapeamento (Model > View Model)
  • ViewModelToDomainMappingProfile > Profile de mapeamento (View Model > Model)

Confira como o projeto ficou estruturado

Projeto ASP.Net MVC AutoMapper

Neste momento resta apenas configurar que a classe AutoMapperConfig seja inicializada junto com a aplicação para registrar os profiles de mapeamento, essa configuração é feita no arquivo Global.asax

using System.Web.Http;
using System.Web.Mvc;
using System.Web.Optimization;
using System.Web.Routing;
using MvcMapping.Mappers;

namespace MvcMapping
{

    public class MvcApplication : System.Web.HttpApplication
    {
        protected void Application_Start()
        {
            AreaRegistration.RegisterAllAreas();

            WebApiConfig.Register(GlobalConfiguration.Configuration);
            FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
            RouteConfig.RegisterRoutes(RouteTable.Routes);
            BundleConfig.RegisterBundles(BundleTable.Bundles);
            AuthConfig.RegisterAuth();

            // Configurando o AutoMapper para registrar os profiles
            // de mapeamento durante a inicialização da aplicação.
            AutoMapperConfig.RegisterMappings();
        }
    }
}

O AutoMapper está devidamente configurado na aplicação, no próximo passo será feita a conversão da Model cliente para a ClienteViewModel na Controller através do mapeamento que foi criado, confira como ficou o código da ClienteController

using System;
using System.Web.Mvc;
using MvcMapping.Models;
using MvcMapping.ViewModels;
using AutoMapper;

namespace MvcMapping.Controllers
{
    public class ClienteController : Controller
    {
        public ActionResult Index()
        {
            var rdnGen = new Random();

            // Um fake de uma consulta de cliente na base de dados.
            var cliente = new Cliente {
                                            Nome = "Eduardo",
                                            Sobrenome = "Pires",
                                            DataNascimento = Convert.ToDateTime("24/04/1982"),
                                            Ativo = true,
                                      };

            // Transformando a Model Cliente em ClienteViewModel
            var clienteView = Mapper.Map<Cliente, ClienteViewModel>(cliente);

            // Atribuindo valor aos dados adicionais da entidade Cliente
            clienteView.NumeroDaSorte = rdnGen.Next(1, 100);

            return View(clienteView);
        }
    }
}

Note que foi necessário apenas uma linha para transformar a Model Cliente em ClienteViewModel. De forma muito elegante foi criado um objeto do tipo ClienteViewModel já populado com os dados existentes no objeto Cliente.

A partir deste momento o AutoMapper está fazendo o trabalho de mapeamento e a View está recebendo uma View Model compatível com suas necessidades, confira o código da View

@model MvcMapping.ViewModels.ClienteViewModel

@{
    ViewBag.Title = "Sorte do Dia";
}

<hgroup class="title">
    <h1>@ViewBag.Title.</h1>
</hgroup>

<table>
    <tr>
        <td>
            @Html.LabelFor(m => m.Nome)
            @Html.DisplayFor(m => m.Nome)
        </td>
    </tr>
    <tr>
        <td>
            @Html.LabelFor(m => m.Sobrenome)
            @Html.DisplayFor(m => m.Sobrenome)
        </td>
    </tr>
    <tr>
        <td>
            @Html.LabelFor(m => m.DataNascimento)
            @Html.DisplayFor(m => m.DataNascimento)
        </td>
    </tr>
    <tr>
        <td>
            @Html.LabelFor(m => m.Ativo)
            @Html.DisplayFor(m => m.Ativo)
        </td>
    </tr>
    <tr>
        <td>
            @Html.LabelFor(m => m.NumeroDaSorte)
            @Html.DisplayFor(m => m.NumeroDaSorte)
        </td>
    </tr>
</table>

@section Scripts {
    @Scripts.Render("~/bundles/jqueryval")
}

Para mapear mais Models / View Models basta editar os arquivos DomainToViewModelMappingProfile e ViewModelToDomainMappingProfile com os mapeamentos necessários.

Achou muito trabalhoso ter que montar a estrutura de pasta e os 3 arquivos de mapeamento? Existe uma forma que dispensa toda essa configuração (inclusive inicialização no Global.asax), basta adicionar uma linha a mais em cada momento que houver o mapeamento, confira.

public class ClienteController : Controller
{
    public ActionResult Index()
    {
        var rdnGen = new Random();

        // Um fake de uma consulta de cliente na base de dados.
        var cliente = new Cliente {
                                        Nome = "Eduardo",
                                        Sobrenome = "Pires",
                                        DataNascimento = Convert.ToDateTime("24/04/1982"),
                                        Ativo = true,
                                    };

        // Criando o Mapeamento por demanda.
        Mapper.CreateMap<Cliente, ClienteViewModel>();

        // Transformando a Model Cliente em ClienteViewModel
        var clienteView = Mapper.Map<Cliente, ClienteViewModel>(cliente);

        // Atribuindo valor aos dados adicionais da entidade Cliente
        clienteView.NumeroDaSorte = rdnGen.Next(1, 100);

        return View(clienteView);
    }
}

Apesar de ser mais simples eu pessoalmente não recomendo utilizar o mapeamento desta forma, pois além de somar uma linha a mais em todo momento de executar o mapeamento, o comando de criação de mapeamento não fica centralizado, é difícil ter visão dos mapeamentos já existentes e dificulta também a manutenção.

Resumo

Utilizar o AutoMapper é muito simples conforme foi exemplificado, colabora para adoção do padrão View Model e evita a necessidade de escrever extensos códigos de mapeamento, assim proporcionando mais agilidade no desenvolvimento e facilitando a manutenção, e claro, o código final fica com um aspecto muito mais elegante.

Existem outras ferramentas para mapeamento com a mesma finalidade, a mais popular até o momento é o AutoMapper.

Referências

Nota

“Como mencionado no artigo anterior o padrão View Model está presente no MVC, MVP e MVVM, este artigo aborda a utilização deste padrão para MVC.”

Espero que este artigo ajude a entender o conceito do padrão View Model e o mapeamento de objetos através do AutoMapper.

Feedbacks são sempre muito bem vindos, utilize os comentários abaixo.

ASP.Net MVC – View Model Pattern – Quando e como utilizar?

No desenvolvimento em ASP.Net utilizando o framework MVC é muito comum o uso do pattern View Model, esse pattern proporciona uma melhor organização do código e gestão dos dados utilizados na View, confira em quais situações ele é utilizável e algumas maneiras de como aplicá-lo.

A necessidade da utilização do pattern View Model surge na maioria dos projetos ASP.Net MVC, para os iniciantes costuma causar alguma confusão, porém é muito útil e poupa um bom trabalho.

O conceito de View Model não limita-se apenas para o ASP.Net MVC, você poderá encontrar referências sobre View Model para padrões MVC, MVP e MVVM, que por sua vez é implementado em tecnologias como ASP.Net, Silverlight e WPF.

Este artigo é dedicado para o entendimento do padrão View Model utilizando ASP.Net MVC.

O que é um ASP.Net MVC View Model?

No ASP.Net MVC os View Models nos permitem modelar várias entidades a partir de um ou mais modelos em um único objeto, eu gosto de usar como exemplo a comparação de View Models com uma DTO, pois ambas são soluções que foram projetadas para centralizar um conjunto de dados de diversas fontes assim evitando a necessidade de realizar várias chamadas para se obter todos os dados necessários e evitar a necessidade de alterar um modelo de domínio para realizar o transporte de algum dado específico.

Resumindo, um View Model representa um conjunto de uma ou mais Models e outros dados que serão representados em uma View que necessita exibir determinado conjunto de informações. A imagem abaixo ilustra o conceito de um View Model:

ASP.Net  MVC View Model Pattern

Utilizando uma View Model dedicada contendo a Model de domínio

Imagine que estamos desenvolvendo uma aplicação web de uma loja virtual onde possuímos a classe Produto:

public class Produto
{
    public string Nome { get; set; }
    public decimal Valor { get; set; }
}

Porém na View de carrinho de compras além das informações contidas na classe Produto é necessário exibir uma mensagem e o valor total do carrinho para vários produtos. O que fazer? Modificar a classe Produtos para conter essas informações?

Modificar a classe Produto não seria uma boa alternativa, afinal esses dados adicionais não fazem sentido pertencerem a entidade Produto, são dados pertinentes a View de carrinho de compras.

É nesse momento que o pattern View Model entra em ação para resolver esse problema de design. Criaremos então uma classe que irá prover dados para esta View e essa classe será uma View Model de carrinho de compras.

public class CarrinhoComprasViewModel
{
	public IEnumerable Produtos { get; set; }
	public decimal TotalCarrinho { get; set; }
	public string Mensagem { get; set; }
}

Podemos observar que esta View Model possui um IEnumerable de Produtos para uma lista de produtos e mais os dados de valor e mensagem que irão ser exibidos na View.
Não é um tipo de classe especial, é uma classe como qualquer outra Model, porém escrita especificamente para atender a uma View.

Confira o código da Controller de carrinho de compras.

public class CarrinhoComprasController : Controller
{
    public ActionResult Index()
    {

        // Criando uma lista de produtos fake para exibição na View
        var produtos = new List<Produto>();
        for (int i = 0; i < 10; i++)
	    {
            produtos.Add(new Produto
                            { Nome = "Produto " + i, Valor = 1.13M * i }
                        );
        }

        // Populando a model para exibição na View
        var model = new CarrinhoComprasViewModel
	    {
            Produtos = produtos,
            TotalCarrinho = produtos.Sum(p => p.Valor),
            Mensagem = "Obrigado por comprar conosco!"
        };

        return View(model);
    }

}

E por fim a View de carrinho de compras

@model MeuExemploMVC.Models.CarrinhoComprasViewModel

@{
    ViewBag.Title = "Carrinho de Compras";
}

<h2>@Model.Mensagem
</h2>
<fieldset>
    <legend>Carrinho de Compras</legend>

    <table>
        <caption>Produtos no Carrinho</caption>
        <thead>
        <tr>
            <th>Produto</th>
            <th>Valor</th>
        </tr>
        </thead>
        <tbody>
        @foreach (var produto in Model.Produtos) {
            <tr>
                <td>@produto.Nome</td>
                <td>@produto.Valor</td>
            </tr>
        }
        </tbody>
        <tfoot>
            <tr>
                <td><strong>Total</strong></td>
                <td>@Model.TotalCarrinho</td>
            </tr>
        </tfoot>
    </table>

</fieldset>

O pattern de View Model está aplicado e não será mais necessário modificar a Model de Produto para adequar a View.

O arquivo físico de uma View Model pode estar em diferentes lugares, sendo:

  • Em uma pasta chamada ViewModels na estrutura raiz do projeto MVC (aplicações pequenas)
  • Uma *.dll referenciada no projeto MVC (aplicações de qualquer tamanho)
  • Em projetos separados (como uma camada de serviços) para gerar dados específicos (aplicações grandes)

Utilizando AutoMapper para realizar o mapeamento de uma Model e suas variantes

Uma outra forma de utilizar View Models seria criando um mapeamento entre a Model entidade de domínio e a View Model que será exibida na View.

Os autores do livro ASP.Net MVC 4 in Action defendem fortemente a utilização de mapeamento entre as Models e suas possíveis variantes.

Com base no exemplo acima, a classe Produto poderia ter uma variante chamada ProdutoViewModel, qual possuiria os mesmos atributos de Produto entre outros mais.

O mapeamento entre essas duas Models seria feito através da ferramenta AutoMapper.
Este é um processo mais complexo e será abordado em meu post exclusivo sobre utilização do AutoMapper.

Benefícios de usar uma View Model

  • Não precisar alterar uma classe Model para atender as necessidades de uma View.
  • Poder agrupar informações de uma ou mais Models em uma única classe, poupando a necessidade de realizar N consultas.
  • Um dado não contido em uma Model de domínio pode ser facilmente transportado através de uma View Model.
  • Mudanças são muito mais fáceis de se realizar e sem afetar a Model do domínio.
  • Não é necessário “poluir” as Models de domínio com DataAnnotations de validação de formulário, pois estas podem estar contidas diretamente na View Model.

Resumo

O uso de View Models é muito recomendado e irá ajudar a organizar e gerenciar os dados a serem transportados e exibidos, proporcionando flexibilidade para montar conjuntos de dados compatíveis com as necessidades da View.

No MVC existe o conceito de separação de responsabilidades onde “M” (Model) é considerada a menos importante, pois nem sempre a Model estará presente no projeto MVC e sim numa camada de domínio que irá prover estas classes. A Model do MVC está voltada ao uso na View, portanto algumas técnicas são necessárias para separar e mapear Models de entidades de domínio para Models do projeto MVC.

Referências

Aguardem o próximo artigo complementar sobre AutoMapper 😉
Dúvidas e feedbacks são sempre muito bem vindos, utilize os comentários abaixo.

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!

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

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:

O que é POCO?

Olá pessoal, O que é POCO? O que seria uma classe POCO?

Hoje em dia utilizar um ORM como Entity Framework ou NHibernate é bem comum, aplicar conceitos do DDD também vem sido bem abordados e discutidos e em todas essas abordagens acaba surgindo o uso de POCO. Afinal o que é POCO?

Tentar decifrar esse nome vai ser bem difícil, POCO significa Plain OLD CLR Object, tentando traduzir isso eu gosto de chamar POCO de “Bom e velho objeto do CLR”.
POCO é um acrônimo de POJO Plain OLD Java Object, criado por Martin Fowler (um expert em OOP) como ele vem de Java acabou dando esse nome, então os especialistas em .Net fizeram uma pequena mudança para trazer esse conceito ao nosso mundo e surgiu o POCO (mas é o mesmo conceito, não muda nada).

Legal, mas ainda não entendi o que é POCO?

É fácil de entender, POCO é uma classe que segue o ideal do OOP, pois tem estado e comportamento, porém não depende e não conhece nenhum recurso externo além do Framework .Net.

Uma classe POCO é utilizada como classe de domínio (negócio) da sua aplicação, o que chamo de Modelo de Domínio. Um Modelo de Domínio é formado pelas classes que compõem a estrutura de negócio do mundo real.

Nós não desenvolvemos sistemas apenas baseados no Framework .Net, quase sempre necessitamos de uma ferramenta externa, por exemplo um ORM, que por sua vez impõe o uso de referências como classes, interfaces, decorações nos métodos etc…

Construir uma classe POCO é escrever uma classe que contenha atributos, construtores e métodos mas que não dependam de nada mais do que o próprio .Net Framework forneça.

Quem já utilizou o Entity Framework na forma Database First já viu como que fica a bagunça de uma classe? Acabamos gerando um único arquivo EDMX com muitas dependências, herdando de um objeto ObjectContext. Geralmente esse código é bastante poluído e dificíl de estender.

    [EdmEntityTypeAttribute(NamespaceName="SistemaOS.Model", Name="Pessoas")]
    [Serializable()]
    [DataContractAttribute(IsReference=true)]
    public partial class Pessoas : EntityObject
    {
        [EdmScalarPropertyAttribute(EntityKeyProperty=true, IsNullable=false)]
        [DataMemberAttribute()]
        public global::System.Int32 id_pessoa
        {
            get
            {
                return _id_pessoa;
            }
            set
            {
                if (_id_pessoa != value)
                {
                    Onid_pessoaChanging(value);
                    ReportPropertyChanging("id_pessoa");
                    _id_pessoa = StructuralObject.SetValidValue(value, "id_pessoa");
                    ReportPropertyChanged("id_pessoa");
                    Onid_pessoaChanged();
                }
            }
        }
    }

Ou seja, estamos amarrados ao Entity Framework se deixarmos ele criar nossas classes de entidades.

Um exemplo simples de classe POCO:

    public class Pessoa
    {
        public string Nome { get; set; }
        public string Sobrenome { get; set; }
        public int Cpf { get; set; }

        public string NomeCompleto()
        {
            return Nome + " " + Sobrenome;
        }
    }

Veja que neste exemplo não dependemos de nada, é apenas uma classe, tratando de DDD o nosso domínio não pode depender de tecnologia, afinal a minha camada de domínio pode ser adaptada a um outro sistema que não utilizará o Entity Framework e tudo bem! Afinal minha classe POCO não depende disso.

Acredito que a vantagem de usar POCO é exatamente essa, podemos modelar nossas classes de domínio e portá-las para onde quiser, sem a dependência de nenhuma ferramenta externa.

Por isso recomendo que utilizem ferramentas que dê suporte a POCO, e isso não é difícil, por exemplo Entity Framework, NHibernate, WCF permitem trabalhar com POCO.

No Entity Framework, por exemplo, podemos trabalhar da forma Code First, ou seja, escrevemos primeiro classes POCO e no final a modelagem da base de dados é criada conforme a modelagem do nosso domínio.

Então uma classe POCO é uma classe anêmica?
– Não! Uma classe anêmica pode até ser uma classe POCO, mas nada diz que uma classe POCO deve ser anêmica, afinal ela pode possuir atributos e métodos.
Uma classe anêmica não possui métodos, e por alguns é considerada um anti-pattern, pois fere o conceito de orientação a objeto, mas isso é assunto para um outro artigo. 🙂

Uma classe POCO é como se fosse uma DTO então?
– Não! Uma DTO “Data Transfer Object” é outra coisa, pense em DTO como uma “sacola de dados”, ou seja, em um objeto DTO podemos ter dados das classes Pessoa, Endereço, Empresa.
DTO é um outro pattern desenhado justamente para reduzir o número de chamadas e a quantidade de dados necessários para trafegar entre camadas de sistemas, por exemplo, entre uma aplicação web e um serviço.
Uma classe POCO é sua classe de domínio e um DTO é o objeto para transitar dados apenas, podem possuir dados de mais de uma entidade e não possuem métodos, portanto não é POCO.

Se minha classe herda de uma classe base então não tenho uma classe POCO?
– Depende, desde que a classe base não tenha nenhuma dependência com outras camadas da aplicação e ferramentas externas, ainda é uma classe POCO.

Referências:

Espero que tenham aproveitado, se você gostou compartilhe esse artigo, se tiver dúvidas ou quiser contribuir com algo faça um comentário.

Até a próxima!

Desenvolvimento Web com .Net – MVC x WebForms

Olá pessoal, o debate MVC x WebForms se tornou muito popular e pretendo abordar o tema aqui também.

Ambas tecnologias são para desenvolvimento Web.

ASP.Net WebForms:

  • Existe desde 2001 (foi o primeiro modelo de desenvolvimento Web com .Net)
  • Tomou o lugar do ASP3 (a maioria dos sites migraram de ASP para ASP.Net)
  • É até hoje o modelo mais utilizado em desenvolvimento ASP.Net.

O WebForms facilitou muito a vida de quem trabalhava com WindowsForms ou VB6, segue o conceito de “drag and drop”, controles muito ricos como o GridView por exemplo com um simples arrastar e soltar.

O WebForms faz sozinho boa parte do trabalho de desenvolver para Web:

  • Gera HTML e JavaScript sozinho.
  • Controla o estado dos controles (postback / viewstate)
  • Os controles fazem praticamente tudo que precisa sem programação extra.

Com tudo isso temos uma boa lista de prós para o WebForms:

  • É RAD (Muito rápido de desenvolver).
  • Controles ricos.
  • HTML e JavaScript automático. “sem necessidade de programar”.
  • Gerenciamento do estado abstraído.
  • Designer Visual.

Mas também temos os contras:

  • Não se tem muito controle do HTML e JavaScript gerado.
  • Alguns controles não estão em conformidades com o W3C.
  • Difícil integração com frameworks JavaScript.
  • A UI (user interface) é quase impossível de se testar.
  • Problemas para utilizar SEO
* Muitas melhorias ocorreram na versão 4.0 do WebForms.

Para entendermos melhor as diferenças vamos fazer uma comparação.

ASP.Net MVC:

  • Segue o padrão arquitetônico de Model View Controller.
  • Faz separação de responsabilidades (cada letra de MVC com a sua).

Para esclarecer, o conceito do MVC não foi criado pela Microsoft (foi pela Xerox em meados de 70), porém foi muito bem adotado e revitalizado.

Quais os prós de se usar MVC:

  • Separação de responsabilidades (cada camada com a sua).
  • Testabilidade.
  • Reusabilidade.
  • Escalabilidade.
  • Manutenção facilitada.
  • Total controle do HTML e JavaScript gerado.
  • Suporta TDD em todos os apectos.

Muito bom né? Agora vamos aos contras:

  • Não é tão RAD quanto o WebForms.
  • Não disponibiliza controle prontos “drag and drop” (mas existem muitos free).
  • A curva de aprendizado é maior, há mais coisas para aprender.
  • Mais coisas para controlar, por ex, sessão de usuário.
  • É necessário desenvolver mais código.

Certo, já deu para balancear?
O que o MVC tem em comum com WebForms:

  • Ambos são ASP.Net (rodam sob o mesmo runtime).
  • Geram páginas ASPX.
  • Rodam no IIS.
  • Acessam dados livremente (ADO.Net, LINQ, Entity Framework).
  • São desenvolvidos no Visual Studio (para MVC é necessário baixar um complemento dependendo da versão do Visual Studio).

Acredito que com base nesses conceitos e diferenças já dá para ter uma ideia de qual abordagem é mais indicada para determinados projetos.

Muitos estão afirmando que o WebForms virou o ASP3 (clássico) ou seja está caindo em desuso. “Quando muitos gurus da tecnologia começam a fazer esse tipo de afirmação a tendência é que se torne uma verdade.”

Afinal qual dos dois escolher para meu próximo sistema Web?

Desenvolver um sistema Web, ASP.Net, desenvolvido em WebForms, na maioria das vezes pode (e vai) atender meu cliente, o que me motiva escolher MVC já que o esforço de desenvolvimento é maior?

As maiores vantagens são:

  • Controle total do HTML e JavaScript gerado.
    Seu site não vai ter o CSS quebrado ou uma função JS desconhecida gerada pelo   ASP.Net. Além de facilitar a compatibilidade com os browsers.
  • Possibilidade de testar a UI
    No WebForms isso é quase impossível, uma vez que não conhecemos o código que ele irá gerar. Para quem usa TDD é essencial ter todas as camadas testadas.
  • Reaproveitamento de código
    O código que é gerado com MVC é seu, você o conhece e o reaproveita onde quiser.
  • Aperfeiçoamento no conhecimento de CSS, HTML e JavaScript.
    Essas tecnologias por mais que bem conhecidas estão em alta, novidades como Windows 8, HTML 5 e o conceito da “Nova Web” são baseadas no uso destes conhecimentos, não dá mais para deixar de lado.

Até então todos desenvolvedores ASP.Net eram adeptos ao WebForms, logo nem sempre encontramos profissionais experientes em MVC (que já está na versão 4).

Cenário:
Você tem um projeto de um sistema web para fazer, o prazo é curto, o sistema não exige uma interface rica e customizada (ainda mais se for uma intranet) e sua equipe não tem conhecimento de MVC, vá de WebForms, não é nesse momento que deverá colocar em prática o aprendizado do MVC.

Eu mesmo gosto do WebForms (assim como já gostei muito de ASP3), trabalhei anos com ele, migrei para o MVC e aos poucos estou convertendo projetos para essa tecnologia.

Minha dica é:
Aprenda! Não deixe de aprender, experimente fazer um projeto em MVC, com o tempo e conhecimento a produtividade volta ao normal, e mais, você se manterá atualizado (MVC já é um pré-requisito para muitas vagas de desenvolvimento).

Por hoje é isso…
Pretendo continuar esse assunto abordando um novo conceito, chamado até então de “Nova Web”. Aguardem.

Quer compartilhar sua experiência? Tirar dúvidas? Utilize os comentários 😉

Referências: