Boas galera,
Vamos a mais um post da nossa série que esta fazendo o maior sucesso!
Cenário: Imaginemos que precisamos transportar informações em uma chamada a um WebService WCF, mas não queremos acrescentar um parametro a mais no método que iremos chamar.
Solução: Uma das soluções possíveis é acrescentar esta informação no cabeçalho da mensagem SOAP. No nosso exemplo vamos transportar uma string que demos o nome a ela de 'HashTag' e seu conteúdo será 'AlgumaCoisa'. Veja o exemplo abaixo.
Na classe do seu servico WCF:
public class ClienteWCF
{
public string HashTag = OperationContext.Current.IncomingMessageHeaders.GetHeader<string>("HashTag", "CustomHeader");
public void MetodoQualquer()
{
if (HashTag == "AlgumaCoisa")
{
//faça alguma coisa...
}
}
}
Na aplicação que irá chamar o WCF ficaria assim:
var clienteWCF = new ClienteWCF.ClienteWCFClient();
using (OperationContextScope scope = new OperationContextScope(clienteWCF.InnerChannel))
{
MessageHeader<string> customHeaderHashTag = new MessageHeader<string>("AlgumaCoisa");
MessageHeader untypedHeaderHashTag = customHeaderHashTag.GetUntypedHeader("HashTag", "CustomHeader");
OperationContext.Current.OutgoingMessageHeaders.Add(untypedHeaderHashTag);
clienteWCF.DoWork();
}
É isso ae galera, fica ae mais esta dica para quem usa e trabalha com WCF.
E não esqueça de curtir e compartilhar para este post também ser útil para outras pessoas.
Um forte abraço e até a próxima...
Boas galera,
Vamos a mais um post da série 'Dicas Rápidas' e hoje vamos falar de WCF e uma situação comum para quem trabalha com WCF e transporta listas de objetos serializados.
Cenário: Imagina que você tem uma lista de Clientes que será enviada pelo WCF e cada cliente tem uma propriedade chamada 'CidadeAtual' que é um objeto do tipo Cidade.
Certo, até ai tudo bem, agora talves vocês não tenham percebido, mas se voce tiver 20 clientes com a mesma Cidade, o objeto Cidade será serializado 20 vezes aumentando consideravelmente o tamanho da mensagem que será trafegada.
Isso também se aplica quando você tem uma estrutura de objetos que geram uma referencia circular, isso pode fazer um loop e a mensagem irá crescendo até estourar o limite de tamanho da mensagem gerando assim um erro.
Solução: Na classe que será trafegada, adicione no DataContract um 'IsReference = true', isso fará com que cada cidade será serializada na sua primeira aparição mas nas subsequentes será criada apenas uma referência para a primeira.
Veja o exemplo abaixo:
[DataContract]
public class Cliente
{
[DataMember]
public string Nome { get; set; }
[DataMember]
public Cidade CidadeAtual { get; set; }
}
[DataContract(IsReference = true)]
public class Cidade
{
[DataMember]
public string Nome { get; set; }
}
É isso ae pessoal, fica ae mais esta dica bastante útil e se gostou ajude-nos curtindo e compartilhando o nosso trabalho.
Um forte abraço a todos e até a próxima...
Mais um post da série 'Dicas Rápidas' vamos abordar uma questão bem complicada para alguns: ViewEngine ou ActionResult?
Uma questão que frequentemente é feita quando alguém deve criar uma ViewEngine personalizada em vez de um ActionResult. Por exemplo, suponha que você deseja retornar os objetos em um formato XML personalizado. Você escreveria uma ViewEngine personalizada ou um MyCustomXmlFormatActionResult?
A regra geral para a escolha entre um e outro é se faz ou não sentido ter algum tipo de arquivo de modelo que orienta a forma como o markup é processado. Se há apenas uma maneira de converter um objeto para o formato de saída, então escrever uma ActionResult personalizada faz mais sentido.
Cenário: Por exemplo, o ASP.NET MVC Framework inclui um JsonResult por padrão, que serializa um objeto em JSON. Você não mudaria a serialização do mesmo objeto para JSON baseado na Action ou na View que será retornada. Serialização geralmente não é controlada através de um modelo.
Mas suponha que você queira usar o XSLT para transformar XML em HTML. Neste caso, você pode ter múltiplas maneiras para transformar o XML em HTML dependendo da Action que foi chamada. Neste caso, você criaria um XsltViewEngine, que utiliza arquivos XSLT como modelo de Views.
Conclusão: ViewEngines tem um propósito muito específico e restrito. Eles existem para levar os dados passados por uma Action e gerar uma saída formatada, geralmente HTML. Mas esse assunto gera muitas e muitas discussões sobre qual forma usar, então na dúvida, implemente da forma que te faça mais feliz.
É isso galera, esperem por mais dicas bacanas, e não esqueça de ajudar outras pessoas compartilhando e curtindo...
Um forte abraço a todos e até a próxima...
Boas galera,
Vamos a mais uma 'Dicas Rápidas', agora vou falar de como você restringir o acesso a determinadas Actions em seus Controllers.
Cenário: Você possui um site desenvolvido usando o ASP.Net MVC e algumas de suas 'páginas' precisa que o usuário esteja conectado para poder ter acesso. Seria um quanto tanto trabalhoso ficar colocando códigos de validação dentro de cada Action, agora imagina que você precise mudar a forma de validação, complicado né?
Solução: Para resolver esse problema, umas das opções seria criar uma ActionFilter que faz a validação e colocar em cima somente das Actions que você queira validar.
Vamos a um exemplo de uma ActionFilter para validação:
public class RequerUsuarioLogadoAttribute : ActionFilterAttribute
{
public override void OnActionExecuting(ActionExecutingContext filterContext)
{
if (ParametrosGlobais.UsuarioLogado == null)
{
filterContext.Result =
new RedirectResult("~/Account/LogOn/" + "?returnUrl=" +
filterContext.HttpContext.Server.UrlEncode(filterContext.HttpContext.Request.RawUrl));
}
}
}
Vocês podem ver acima que faço uma verificação e se caso o usuario não estiver logado, eu redireciono para a página de autenticação e já passo como parâmetro a página que o usuário tentou acessar, para que depois de autenticado o sistema redirecione novamente para a página de origem.
Agora para usarmos basca colocar em cima de uma Action como demonstro abaixo:
public class ClienteController : Controller
{
[RequerUsuarioLogado]
public ActionResult CreateCliente()
{
//sua implementação para incluir cliente
return View();
}
}
Galera, uma ActionFilter pode ser usada para várias finalidades e com ela você pode rodar uma código tanto antes de entrar no código da Action, como também rodar um código depois dos códigos da Action.
É isso ae, e não esqueça de ajudar outras pessoas divulgando, curtindo, twitando, compartilhando os posts e você pode utilizar alguns dos botões abaixo para isso.
Um forte abraço a todos e até a próxima...
Boas galera,
Vamos a mais um post da série 'Dicas Rápidas' com o Atributo 'Obsolete', mas antes disso gostaria de agradecer a todos que estão elogiando bastante a qualidade das matérias do blog e em especial essa série que pelo que estão falando, já está a gerar frutos ajudando muita gente.
Cenário: Muitas das vezes estamos desenvolvendo um sistema complexo seja em equipe ou até mesmo sozinho, e em algum momento precisamos melhorar, evoluir ou modificar uma determinada classe ou método, ou até mesmo substituí-los por outros, mas como alguns sabem, só que algumas vezes mudar uma implementação pode ser sinônimo de destruição e tentando evitar isso fizeram um princípio chamado OCP (Princípio do Aberto-Fechado) que fala que toda classe, método, módulo, function e outros são fechados para modificação e aberto para extensão.
Vejam o próprio .Net Framework que a partir da versão 2.0, quando surgem melhorias são criadas classes novas ou métodos novos e os antigos continuam funcionando mas os antigos são decorados com o Atributo 'Obsolete' que é o assunto em questão deixando um aviso no Visual Studio dizendo por ex. que uma classe está obsoleta.
Uso: Para se decorar uma classe por ex. como obsoleta iremos decorar com o Atributo 'Obsolete', mas deverá escolher se você quer apenas avisar que está obsoleto ou alem de avisar, impedir a compilação caso a classe obsoleta esteja em uso no sistema. Isso é muito útil para sabermos onde a classe esta sendo usada para podermos corrigi-lo, ou avisar outras aplicações.
Neste exemplo abaixo temos duas situações, a primeira na classe A a gente apenas avisa que a classe está obsoleta, indicando qual classe deve ser usada agora, ja na classe B a gente decora o método 'AntigoMetodo', mas reparem que colocamos o 'true' depois da mensagem, para que se alguem usar este método, a compilação seja impedida.
Exemplo:
[System.Obsolete("Use a classe B")]
public class A
{
public void Metodo() { }
}
public class B
{
[System.Obsolete("Use NovoMetodo", true)]
public void AntigoMetodo() { }
public void NovoMetodo() { }
}
É isso ae galera, espero mais uma vez que este post seja de bastante utilidade e foi bom que vocês conheceram um pouco sobre um dos princípios SOLID, mas não se preocupem que iremos falar do SOLID em outros posts.
E mais uma vez peço que ajudem a divulgar os nossos posts através dos botões abaixo para que outras pessoas como você possa aprender mais, pois é somente assim que iremos atingir o objetivo de ajudar o maior número de pessoas.
Um forte Abraço a todos e até a próxima...
Boas galera,
Hoje venho falar sobre uma coisa muito importante que é o ciclo de vida de uma aplicação MVC.
Todo desenvolvedor que for se aventurar no mundo do ASP.Net MVC ou mesmo pessoas que já usam, é obrigatório conhecer o seu ciclo de vida.
Acima na imagem você pode ver desde a requisição ao servidor (HTTP Request) até o retorno para o navegador (Response).
Abaixo descrevo de forma mais simplificada as suas etapas:
- HTTP Request: É a porta de entrada do servidor que receberá a sua requisição e as informações para que todo o processo se inicie.
- Routing: É aqui onde onde o MVC identifica qual formato da rota ele vai usar baseado nas configurações definidas no 'global.asax', então ele pegará a rota correta baseado em sua requisição e direcionará para o Controller correto.
- Controller: Aqui é chamado a Action correta contendo a sua principal lógica de negócio alem de definir se usará uma View e qual View será usada.
- ViewResult / ViewEngine / View: Agrupei este 3 pois eles andam de mãos dadas. Definido o tipo de ViewResult que será usada e os dados que serão enviadas para a View, é na ViewEngine(Asp.Net, Razor, etc) onde o MVC pegará os dados vindo do Controller e uma View e montará o resultado a ser devolvido.
- Response: O resultado das informações será enviada para o navegador.
Observações:
- Preciso dizer que nem toda requisição para o servidor necessita propriamente de uma View, bem como nem todas as requisições retornam um HTML, pode ser um XML, JSON, etc.
- Quase em todas as etapas descritas poderá conter uma lógica, bem como uma etapa poderá pular alguma outra etapa, isso vai depender muito do cenário que você escolheu.
- Quando eu me refiro a 'dados' que será enviado para a View nem sempre eu estou falando do Model, pois posso enviar outros tipos de informações pela ViewBag.
Aqui eu tentei simplificar ao máximo como é o ciclo de vida de uma aplicação ASP.Net MVC e espero que tenha ajudado, até a próxima...
Ahh e eu ja ia me esquecendo...
Se você gostou ou se foi útil para você, não deixe de ajudar a divulgar utilizando as opções de redes sociais pois outras pessoas podem precisar.
Boas galera,
Vamos a mais um post da série "Dicas Rápidas" e hoje vamos falar de Entity Framework.
Cenário: Quando usamos um ORM, em especial o Entity Framework, nos utilizamos e gostamos muito de um recurso chamado "Lazyload" ou "Carga Tardia" que nada mais é do que em acessar os dados no banco somente quando os dados forem realmente necessários. Imaginamos você consultar um pedido e neste pedido você terá uma lista de produtos. Quando se usa Lazyload esta lista de produtos será substituida por um objeto que contem um Proxy, e somente quando você precisar acessar alguma informação de um ou mais produtos desta lista é que o ORM vai buscar os dados. Caso você implemente um código mas o framework perceber que você não precisa dos dados em nenhum momento, ele economizará esta ida ao banco.
Problema: O Lazyload é muito útil em inúmeras situações, alem de ser muito conveniente, mas em alguns casos pode custar caro. Imaginamos que tenhamos 100 produtos em nossa lista, e em algum momento você precise acessar alguma informação desses produtos, nesta situação infelizmente o ORM terá que fazer 101 queries para trazer os produtos, ou seja, N+1.
Solução: Para otimizar e reduzir o numero de queries utilizamos na construção do Linq o 'Include'.
Exemplo:
var pedido = (from p in context.Pedidos
.Include("Produtos")
select p).FirstOrDefault();
ou podemos com lambda:
var pedido = context.Pedidos.Include(p => p.Produtos).FirstOrDefault();
Então é isso ae pessoal, até a próxima...
Ahh e eu ja ia me esquecendo...
Se você gostou ou se foi útil para você, não deixe de ajudar a divulgar utilizando as opções de redes sociais pois outras pessoas podem precisar.
Boas galera,
Esta é o segundo post de uma série de dicas chamada "Dicas Rápidas" onde postarei sempre dicas de vários níveis e tecnologias e neste segundo post mostrarei uma dica de Razor para o ASP.Net MVC3.
Cenário: Muitas das vezes estamos construindo uma View em MVC3 utilizando Razor e utilizamos @if para verifica uma condição e dentro das chaves { } colocamos os nossos códigos dependendo da condição, so que na maioria das vezes utilizamos tags html como por ex:
@if ( variavel == 3)
{
<strong>Codiçao 1</strong>
}
else
{
<strong>Condiçao 2</strong>
}
Neste caso nosso código funcionará perfeitamente, pois o Razor tem a capacidade de saber quando é código C# e quando é código HTML. Depois da primeira chave { o Razor pega o sinal de menor < e identifica que ali é uma tag HTML e já vira para HTML, quando ele identificou o else ele volta para C#. Mas há situações onde não queremos formatar um texto e nem fazer nada, somente imprimir o texto e neste caso se fizermos assim:
@if ( variavel == 3)
{
Codiçao 1
}
else
{
Condiçao 2
}
Ocorrerá um erro pois o Razor terá dificuldade de saber se 'Codiçao' é ou não um código C# e para isso temos 2 formas de informar ao Razor para força-lo a virar para HTML.
Dica 1
@if ( variavel == 3)
{
<text>Codiçao 1</text>
}
else
{
<text>Condiçao 2</text>
}
Dica 2
@if ( variavel == 3)
{
@: Codiçao 1
}
else
{
@: Condiçao 2
}
Espero ter ajudado em mais esta dica, e aguarde as próximas...
Ahh e não esqueçam...
Se você gostou ou se foi útil para você, não deixe de ajudar a divulgar utilizando as opções de redes sociais no cabeçalho deste post pois outras pessoas podem precisar.
Bom dia galera,
Começarei hoje uma nova categoria chamada "Dicas Rápidas". Será pequenos posts com dicas e truques úteis no dia-a-dia de um desenvolvedor.
Serão dicas de todos os tipos e tecnologias, algumas poderão ser simples e de conhecimento da maioria das pessoas, outras de nível médio, e também terá dicas avançadas usadas e conhecidas por um número menor de pessoas.
Começaremos nosso primeiro post da série com uma dica simples mas muito útil.
Cenário: Muitas vezes em projetos ASP.Net seja Webform ou MVC, precisamos enviar tags HTML e/ou Javascritp para a View e nos deparamos com um erro do Framework dizendo que por questão de segurança o código não poderá ser exibido, ou em outros casos as tags ou javascritp aparece como um texto, mas não é isso que queremos.
Observação: Tenha cuidado em usar esta dica, pois se mal usado pode trazer um risco sério a segurança da sua aplicação permitindo a injeção de códigos maliciosos.
Solução: Utilize o método @Html.Raw para MVC Razor ou <%= %> para ASP.Net em seu código para dizer ao Framework que você autoriza o envio do código para a View.
Exemplo:
@Html.Raw("<br />Meu texto<br />com quebra de linhas<br />");
<%= "<br />Meu texto<br />com quebra de linhas<br />" %>
Espero ajudar muita gente no seu dia-a-dia com estas dicas e até a próxima...
Ahh e não esqueçam...
Se você gostou ou se foi útil para você, não deixe de ajudar a divulgar utilizando as opções de redes sociais pois outras pessoas podem precisar.
Pessoal,
Uma excelente notícia para quem tem interesse em tirar uma certificação microsoft.
A MS está com uma promoção comemorando 20 anos de certificação e esta distribuindo voucher para efetuar exame grátis.
Os exames participantes da promoção são:
- Exam 70-583: PRO: Designing and Developing Windows Azure Applications
- Exam 70-640: TS: Windows Server 2008 Active Directory, Configuring
- Exam 70-659: TS: Windows Server 2008 R2, Server Virtualization
- Exam 70-662: TS: Microsoft Exchange Server 2010, Configuring
- Exam 70-664: TS: Microsoft Lync Server 2010, Configuring
- Exam 70-573: TS: Microsoft SharePoint 2010, Application Development
- Exam 70-599: PRO: Designing and Developing Windows Phone Applications
Para mais informações acesse:
http://www.microsoft.com/learning/en/us/certification/20yrs20ways.aspx