Dando continuidade ao post anterior “Iniciando com WCF”, vamos ver hoje um pouco sobre a arquitetura WCF.
A figura 1 mostra a arquitetura principal do Windows Communication Foundation. Vamos ver cada item par que você possa começar a se familiarizar com o WCF.
Figura 1 – Arquitetura WCF
Contracts
O contrato expõe quais membros de uma classe serão visíveis. Através de interfaces podemos definir um contrato entre um serviço e as aplicações que irão consumí-lo, expondo somente os métodos desejados.
O WCF conta com os seguintes tipos de contratos:
- Service Contract - Um contrato para um serviço. Define os detalhes do serviço, e será utilizado na interface de contrato.
- Operational Contract - Define uma operação individual, e será aplicado na assinatura dos métodos da interface de contrato.
- Data Contract - Define a serialização para objetos complexos. Esta propriedade necessita da inclusão do namespace System.Runtime.Serialization.
- Message Contract - Este contrato descreve a mensagem SOAP completa.
- Fault Contract - Utilizado para documentar erros no WCF.
Policies and Binding - Especifica as condições que serão requeridas para a comunicação, como exemplo podemos destacar os requisitos de segurança a serem utilizados na comunicação com o serviço.
Os contratos do WCF são utilizados como propriedades, podendo ser atribuído a classes e interfaces.
Service Runtime
Ele contém os comportamentos que ocorrem durante a execução do serviço.
- Throttling Behavior: controla quantas mensagens são processadas.
- Error Behavior: especifica um erro interno ocorrido no serviço.
- Metadata Behavior: informa como e se os metadados estarão disponíveis.
- Instance Behavior: especifica quantas instâncias do serviço deverão ser criadas durante a execução do serviço.
- Transaction Behavior: permite a reversão de operações caso uma falha venha a ocorrer.
- Dispatch Behavior: controla como uma mensagem é processada pela infra-estrutura do WCF
Messaging
A camada Message é composta de Canais. Canais são componentes que fazem o processamento das mensagens, por exemplo, autenticando uma mensagem.
Um conjunto de Canais é conhecido como Channel Stack. Os canais são o núcleo para o envio e recebimento de mensagens para um EndPoint.
Existem dois tipos de canais:
- Transport Channels: realiza o envio/ recebimento de mensagens pela rede. Ex.: HTTP, TCP e MSMQ.
- Protocol Channels: implementa o protocolo SOAP possibilitando a modificação da mensagem. Ex.: WS-Security e WS-Reliability.
Activation and Hosting
Para que um serviço possa ser consumido ele deve estar ativado e hospedado. No caso do WCF, este pode ser hospedado de diversas formas como:
- IIS – Internet Information Service: provê várias vantagens como controle do serviço. Porém só pode ser utilizado o protocolo HTTP para o tráfego de informações.
- Windows Activation Service - (WAS)
É uma forma mais atual de ser ativar um serviço, foi incorporado ao IIS 7. Trabalha com os seguinte protocolos: TCP e Named Pipes.
- Self-Hosting
- WCF Service pode ser hospedado também em um aplicativo do tipo Console Application, Windows Form ou aplicações gráficas WPF.
- Windows Service
- WCF também pode ser hospedado em um Serviço do Windows onde você pode ter o controle do aplicativo pelo Service Control Manager (SCM).
Como podem ver o WCF nos dá uma flexibilidade muito grande quanto a forma de hospedagem o que nos abre um enorme leque de possibilidades.
Aguardo vocês no próximo post!!
Enjoy!
Fala pessoal, tudo na paz?
Bem, como ando recebendo e-mails da galera perguntando sobre WCF, resolvi escrever alguns artigos sobre ele.
Nessa primeira parte vamos ver o que é o WCF e o que o compõe. Será uma introdução básica, porém, espero colocar toda informação necessária para um primeiro contato.
Primeiramente, o que é o WCF?
Windows Communication Foundation ou WCF como é mais conhecido nada mais é do que um SDK para desenvolvimento de aplicações distribuídas e orientadas a serviço, também conhecidas como (SOA).
O WCF surgiu no .Net Framework 3.0. Ele veio para unificar tecnologias como COM+, .Net Remoting, Web Services e MSMQ (Microsoft Message Queue), isso porque, antes do WCF, era necessário que o desenvolvedor utilizasse tecnologias distintas para cada tipo de aplicação, um exemplo seria a criação de Web Services para disponibilizar na Internet algum serviço. Caso este serviço fosse disponibilizado na intranet, deveria ser criada uma aplicação utilizando .Net Remoting, isso porque .Net Remoting utilizava o protocolo TCP enviado arquivos binários pela rede o que tornava a aplicação muito mais rápida do que com Web Service (Http/XML). Com a criação do WCF isso deixa de existir, ele torna a vida do programador muito mais simples.
Para que possamos criar, projetar e implantar serviços WCF, devemos nos ater a alguns conceitos básicos que são os EndPoints e seus componentes ( Address, Binding e Contract).
Toda comunicação com o serviço se dá através dos EndPoints, são eles os responsáveis por fornecer aos clientes o acesso às funcionalidades do serviço.
Calma pessoal não se assustem, vamos ver em detalhes cada pedacinho que compõe um EndPoint. Vamos lá?
Address
Nada mais é do que o local ou endereço onde o serviço reside. O Address possui dois pontos importantes que são a localização e o protocolo de transporte. Um Address possui o seguinte formato:
[base address]/[optional URI]
Já o base address segue o seguinte formato:
[transport]://[machine or domain][:optional port]
Como transport, o WCF nos oferece os seguintes canais de comunicação:
http, https, net.tcp, net.pipe, net.msmq e net.p2p
Para ilustrar melhor abaixo temos alguns exemplos de Address:
http://localhost:8080
http://localhost:8080/MeuWCFService
net.tcp://localhost:123/MeuWCFService
net.pipe://localhost/MeuWCFService
net.msmq://localhost/private/MeuWCFService
net.msmq://localhost/MeuWCFQueue
Binding
É o responsável por definir como será a comunicação com o serviço (tcp, ipc, http, msmq, etc).
O WCF nos oferece seis tipos de binding que são:
- BasicHttpBinding
- NetTcpBinding
- NetNamedPipeBinding
- WSHttpBinding
- WSDualHttpBinding
- NetMsmqBinding
Para saber mais sobre Binding, deem uma olhada no post WCF Bindings.
Contract
No contrato é onde definimos quais funcionalidades um serviço irá expor para os clientes.
Existem quatro tipos de contrato que são:
Service Contracts:
- define quais operações estarão disponíveis no serviço para o cliente., ou seja, mapeia tipos CLR para WSDL
Data Contracts:
– define a estrutura de dados usada no serviço, ou seja, ele mapeia tipos CLR para XSD
Fault Contracts:
- define os tipos de erros que serão lançados pelo serviço e como eles irão propagar para o cliente.
Message Contracts:
- define a estrutura de mensagens usadas no serviço, ou seja, mapeia tipos CLR para SOAP
Então, para que tenhamos um EndPoint precisamos ter um Address, um Binding e um Contract, estes itens são conhecidos como ABC´s EndPoint.
Bem pessoal, por hoje é só!
Em nossos próximos posts iremos nos aprofundar um pouco mais no WCF.
Espero que tenham gostado desta primeira parte.
Enjoy!!
Outro dia estava trabalhando em um projeto onde precisava criar alguns métodos a mais para uma dll que havia sido gerada para um outro aplicativo. Porém, como não tinha o código fonte dela estava prestes a escrever uma nova classe e implementar os métodos que estava precisando, mas antes de começar a codificar, me lembrei que a partir da versão 3.0 do Net Framework, a Microsoft incluiu uma funcionalidade muito bacana chamada Extension Methods.
Mas o que são Extension Methods?
Basicamente é uma forma de você “inserir” código em classes já compiladas mesmo que estas sejam seladas (sealed) como a maioria das classes do .Net Framework. Desta forma podemos incrementar nossas classes com métodos que criamos sem a necessidade de realizar uma recompilação da mesma.
Mas para que isso fique mais claro, vamos ao exemplo.
Crie um projeto do tipo C# -> Console Application, dê o nome de “ExtensionMethods”.
Agora crie um novo projeto do tipo C# –> Class Library, e dê o nome dele de MyClass. Agora renomeie a Class1.cs para Client.cs. Seu projeto deverá estar como na figura 01.
Figura 01 – Solution Explorer
Agora, abra o arquivo Client.cs e adicione o código da listagem 01.
Listagem 01 – class Client.cs
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace MyClass
{
public sealed class Client
{
public string Name { get; set; }
public string Email { get; set; }
public bool EmailIsValid()
{
return !string.IsNullOrEmpty(Email);
}
}
}
Observem que criamos duas propriedades e um método que “valida” o email do cliente.
Vamos criar nossa chamada à classe Client. Abra o arquivo Program.cs e insira o código da listagem 02 no método Main da classe.
Listagem 02 – chamada a classe Cliente
var cl = new Client
{
Email = "lima@lucianolima.com.br",
Name = "Luciano Lima"
};
Console.WriteLine( cl.EmailIsValid() ? "Email Válido" : "Email Inválido" );
Console.ReadLine();
Ao executar este código ele irá apenas escrever Email Válido porque a propriedade Email está preenchida.
Bem, digamos que você precise realizar a validação do Nome do Cliente, mas sem ter que mexer na classe Client, é ai que Extension Methods entra em ação.
Adicione uma nova classe no projeto ExtensionMethods, dê o nome a ela de “ClientExtension.cs” e insira o código da listagem 03.
Listagem 03 – class extension
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using MyClass;
namespace ExtensionMethods
{
public static class ClientExtension
{
public static bool NameIsValid(this Client client)
{
return !string.IsNullOrEmpty(client.Name);
}
}
}
O importante nessa classe é a forma como criamos o método, observem que o segredo para a funcionalidade de extensão é a palavra “this” que faz referencia à classe que queremos agregar operações, o restante é código puro e simples.
Agora quando for utilizar a funcionalidade, o Visual Studio irá detectar que este método é uma extensão para a classe Client, conforme figura 02 e figura 03.
Figura 02 – método estendido na classe Client
Figura 03 – ToolTip mostrando que o método é uma extensão.
Extension Methods como falei acima pode ser aplicado a todas as classes do dot Net Framework, então caso precise de um método exclusivo para trabalhar com string basta criar sua classe de extensão e implementar o método que achar necessário. Mas cuidado, a manutenção deste tipo de código pode ser um pouco árdua por isso, pense bem antes de sair criando extension methods.
Enjoy!!
Hoje vamos mudar um pouco nossas conversas, não vamos falar nem mostrar uma linha de código se quer. Bem, não sei nem por onde começar esta discussão, mas vou tentar colocar da melhor forma possível e depois deixo minha opinião e espero que vocês possam contribuir deixando a opinião de vocês. Aliás, para os menos avisados, NÃO EXISTE o Design Pattern TSF, na verdade estou chamando assim porque muitos, assim como eu, já brincaram de telefone sem fio quando criança e é exatamente isso que encontramos na maior parte das empresas quando se fala em desenvolvimento de software.
Você deve ter ficado meio confuso com isso não é? Como uma brincadeira de criança pode estar presente numa empresa que desenvolve software? “O Luciano ficou maluco? Telefone sem fio pra desenvolver sistemas? É, realmente ele pirou de vez!!”. O que posso dizer é, esse modelo de desenvolvimento existe e é amplamente utilizado!
Bom, antes de começarmos, gostaria de dizer os motivos que me levaram a escrever sobre esse assunto. O primeiro deles é porque estou estudando metodologias de desenvolvimento, o segundo é que percebi que terei mais uma vez que quebrar o paradigma para a construção de um software e o terceiro e último motivo é pelo simples prazer em compartilhar um pouco da minha experiência.
Para tentar explicar o que acabei de citar acima vamos ver um exemplo, qualquer coincidência é mera realidade (rsrs), para que vocês possam entender melhor o que estou dizendo.
Suponhamos que você seja o analista de uma fabrica de software e que seu mais novo projeto seja desenvolver um sistema para uma empresa de investimentos, uma corretora de valores.
Tudo começa quando você vai até o cliente e discute com ele tudo que ele precisa no novo software (Home Broker). A par do projeto e das necessidades do cliente, você irá discutir com o Analista de Negócios, pois ele, mais do que ninguém, possui o conhecimento de todo o funcionamento de um Home Broker. De posse de toda informação e de anotações feitas durante a discussão com o Analista de Negócio e com o cliente, você dá inicio ao processo de documentação, seguindo ou não algum padrão (isso vai de empresa para empresa, de analista para analista).
Findado este processo de documentação você irá validar estes documentos junto ao Analista de Negócio. Dada tal aprovação, o próximo passo é passar tudo para o Coordenador da equipe de desenvolvimento para que o mesmo possa repassar para os programadores e DBA´s suas tarefas para que os mesmos coloquem o desenvolvimento do projeto em prática.
A maioria dos projetos que trabalhei e que trabalho seguem essa linha de raciocínio, e isso não é exclusividade de uma ou outra empresa, esta forma de trabalho é geral, encontrada também em grandes empresas, posso citar dentre as quais trabalhei CEF e FGV.
Até ai tudo bem, não vimos nada demais só que como todo bom projeto, começam a surgir algumas dúvidas (digamos que sejam as regras de negócio, e olha que você documentou tudo heim!!) e logo um dos programadores irá até seu Coordenador tentar sanar a dúvida. Qual será a reação do Coordenador? Isso mesmo, ele irá até você (Analista de Sistemas) e, assim como ele, você irá até o Analista de Negócios tentar da melhor forma possível captar informações suficientes para sanar a dúvida do Coordenador que por sua vez irá repassar para o programador. Algo soa familiar a alguma brincadeira da sua infância? Alguma mera semelhança com o “Telefone sem Fio”? Não né!
E um dos problemas que vejo nessa forma de trabalho é quando as informações começam a sofrer distorção, ou seja, nem tudo é passado de forma correta para o pessoal de desenvolvimento gerando pequenas falhas no software e quando for enviado para a equipe de testes, muitos erros serão detectados fazendo com que o software volte para ser refeito gerando atrasos não planejados e consequentemente insatisfação por parte do cliente.
Os padrões de desenvolvimento de software são bons, mas como tudo que diz respeito à tecnologia, metodologias, conceitos e padrões, também precisam evoluir, e talvez um pouco mais de flexibilidade nestas comunicações seja uma forma de adicionar flexibilidade e minimizar os ruídos de comunicação.
Desculpem pelo longo período sem posts, mas é que estava de férias e aproveitei pra me “desligar” um pouco do computador e esfriar a cabeça.
Hoje quero falar sobre um assunto que sempre gera conflito, como podem observar o título do post.
Mas isto é verdade? Bem, vou deixar aqui “minha” opinião, espero que leiam e reflitam sobre ela e caso não concorde deixe seu comentário baseado em fundamentos. Vamos lá.
De alguns anos pra cá andei observando que muitos programadores sentem “pavor” de certos códigos mesmo que, estes códigos tenham sido desenvolvidos por ele. Mas porque isso acontece?
O que pude observar é que em projetos de software basicamente temos os seguintes requisitos base: Custo, Escopo e o Prazo. Geralmente para que o projeto dê certo, devemos analisar junto ao cliente quais são os dois pontos mais importantes para ele. Observem que eu disse “dois pontos” e não “três pontos”, isso porque devemos fixar dois desses três pontos para que nosso projeto possa fluir da melhor forma possível. Sendo assim, o cliente pode optar por um projeto que terá uma duração de 2 meses (prazo) com um custo máximo digamos de cem mil (custo) deixando assim uma flexibilidade para o Escopo. Ou ainda definir o prazo e o escopo deixando o custo flexível e até mesmo fixando o custo e o escopo, deixando um prazo mais flexível. Isso iria variar de projeto para projeto e de cliente para cliente.
Esta seria a melhor forma de se trabalhar. Porém a realidade é outra. O que se tem nos dias de hoje é que o cliente fixa os três pontos, além de definir em um curto prazo um escopo quase impossível de ser concluído. Isso faz com que percamos as compensações no três itens base, custo, prazo e escopo.
Com base nesse cenário é que começam a surgir os problemas.
Como o escopo é fixo e os recursos também, é no prazo que sofremos, pois estaremos sempre atrasados, obrigando-nos a fazer horas extras, perder fins de semana e por ai vai.
Mas isso ainda não é tudo, o que pesa mais é a cobrança que o desenvolvedor sofre. É uma carga muito pesada para ele carregar. E é justamente nesse ponto que entra uma questão muito importante, “você sabe o que acontece quando você pressiona um desenvolvedor por prazo?”. Bem, posso citar varias coisas mas a principal delas é a QUALIDADE do serviço. Ela é reduzida drasticamente e isso é um fato. Imagino que se os gerentes de projeto tivessem essa informação eles iriam pensar duas vezes antes de se dobrarem sobre os ombros de um desenvolvedor e fazer aquelas famosas perguntas:
- “dá pra andar um pouco mais rápido? “
- “já terminou?”
- “dá pra entregar dia tal?” (essa é de doer!)
O pior disso tudo é que o programador, na maioria das vezes se vê obrigado a aceitar essa pressão e, para que isso aconteça, ele acaba cortando qualidade para atender o prazo. E tem mais, ele não conta que está cortando qualidade (para ficar dentro do prazo estipulado), e o gerente de projeto fica em uma situação ainda pior. Mas há também vezes em que o desenvolvedor sequer percebe que está cortando a qualidade.
É justamente nesse ponto que temos os chamados “códigos mal feitos”, códigos que dão pavor de serem alterados, pois qualquer alteração pode vir a se tornar uma dor de cabeça ainda maior. É onde também, na maioria das vezes ocorre o que chamamos de POG (Programação Orientada a Gambiarra), o desenvolvedor está tão concentrado no prazo que se vê obrigado a fazer de tudo para que o sistema funcione.
O que vem depois disso é ainda pior, o cliente recebe um software mau feito que gera inúmeros erros e na visão dele, o desenvolvedor é visto como um cara que só faz porcaria e que é um incompetente.
Este é um típico caso que já presenciei em várias empresas, esta não é uma realidade fictícia, isso é realmente o que ocorre. O problema é que não fazemos nada para mudar esta situação então deixo aqui aberta uma discussão sobre o assunto e espero que possamos chegar a um consenso para que nossa profissão possa ser vista como primordial e não como um bando de incompetentes.
Outro dia estava conversando com um amigo sobre as mudanças que o .Net vem sofrendo com o passar dos anos. Uma das coisas que ele me questionou foi: “var veio pra substituir o Object…e agora o Dynamic veio pra substituir o var?”. Bem, vamos ver o que realmente são cada um destes tipos.
Como todos sabem, Object é a classe base na plataforma .net, System.Object, ou seja, muitos dos tipos que conhecemos tem sua descendência de Object mesmo isso não sendo explicitado. Sendo assim elas passam a herdar seus comportamentos e suas propriedades, como por exemplo Equals(Object obj), ToString() , GetHashCode() dentre outros.
Atento para a informação de que quando falamos que “tudo herda de Object” estamos sendo equivocados. Caso queiram ler mais sobre o assunto sugiro o post do Eric Lippert.
Com isso, quando criamos uma variável do tipo Object ela tem a capacidade de receber qualquer valor. Vamos ver um exemplo.
Listagem 01
String str = "Luciano"; // declaração do tipo String
Object obj = str; // boxing
String s = (String)obj; // unboxing
Observem que defini a string “Luciano” à variável str que é do tipo String. Criei uma nova variável só que desta vez do tipo Object e informei que ela receberia o conteúdo da variável str, conhecemos isso como Boxing. Criei uma nova variável o tipo String, como havia dito antes, como todos os tipos derivam de System.Object, o tipo String poderá receber o valor da variável obj, pois foi atribuído a ela uma string. Porém precisamos realizar um “cast” que é uma conversão de tipos, pois como Object aceita qualquer coisa precisamos informar que ao passar o conteúdo de obj para outra variável de outro tipo teremos que informar pra qual tipo ela irá se “converter”. Conhecemos isso como Unboxing.
Vamos ver agora o tipo var
Primeiramente, só variáveis podem ser declaradas como sendo do tipo var. Bem, se eu declarar uma variável assim, quando eu for utilizar ela, ela poderá ter qualquer valor? Não. Isso porque o compilador não deixa você declarar uma variável somente com var sem fazer uma atribuição logo na declaração, pois é através dessa atribuição que ele vai inferir o tipo da variável, ou seja, sempre que você for utilizá-la ela terá um tipo já atribuído.
O conceito var pode nos remeter a pensar que estamos regredindo e deixando com que a linguagem se torne não tipada, que será uma coisa ruim, porém não é bem assim. Vamos ver realmente uma aplicação para o conceito de var.
Listagem 02
var objVariante = new
{
Nome = "Luciano",
Email = "teste@teste.com.br",
CPF = 0123456789
};
Basicamente são tipos definidos de maneira dinâmica, sem necessitar de um tipo explicito previamente definido. Observe a figura 01
Figura 01 – Criação de um tipo Anonymous
Com esta construção armazenamos duas propriedades somente leitura em um tipo anônimo representado pela variável objVariante. Um detalhe importante sobre os anonymous types é que eles não são tipos genéricos e não causam boxing e unboxing de uma maneira oculta, eles são realmente objetos fortemente tipados, a diferença é que o compilador gera a implementação para nós onde lhe for conveniente.
As aplicações para o var são muitas, porém as que realmente fazem sentido são as aplicadas a LINQ.
E finalmente dynamic
O conceito de dynamic muda um pouco do conceito que conhecemos até o momento, pois trás o poder das linguagens dinâmicas e mescla vantagens e desvantagens com a linguagem estática que é o C#. O dynamic não se restringe somente a variáveis, ele pode ser aplicado a propriedades, retorno de métodos, parâmetros, praticamente tudo. Quando você declara utilizando o dynamic está dizendo para o compilador que o objeto ali contido é desconhecido e que todas as operações efetuadas envolvendo este objeto só serão checadas em tempo de execução ( runtime ), sendo assim é possível invocar um método inexistente sem que o compilador dê erro, quando acontecer a chamada desse método é que o acontecerá verificação desse método, checagem de parâmetros e tudo mais, se algum problema for identificado durante a verificação ocorrerá uma exceção. Com esse recurso infelizmente perdemos qualquer ajuda da IDE em relação ao intellisense, pois o conceito do dinamismo impede que saibamos sobre informações do objeto de forma prévia.
Veja um exemplo na figura 02
Figura 02 – Declaração de um objeto do tipo Dynamic
Reparem que não existe intellisense, apenas uma informação da IDE dizendo que a chamada ao método Do() será resolvida em tempo de execução. Mas se perdemos em parte com isso qual a utilidade de se usar dynamic?
Umas das grandes vantagens é a utilização de Reflection e COM Interop. Veja um exemplo.
Listagem 03
dynamic inteiro = Activator.CreateInstance( Type.GetType( "System.Int32" ) );
Console.Write( inteiro ); // Irá imprimir 0 no console
dynamic data = Activator.CreateInstance( Type.GetType( "system.DateTime" ) );
Console.Write( data ); // Imprimirá 01/01/0001
Além disso, permite a interação com linguagens dinâmicas como IronPhyton e IronRuby, possiblidade de consumir e executar códigos escritos em IronPhyton e IronRuby dentro do C#.
Como puderam observar, todos três tipos possuem características próprias e cada um irá executar uma função diferente dentro da programação, sendo assim, nenhuma delas veio para substituir a outra, mas sim para agregar valores à linguagem C#.
Voltado para desenvolvedores web, essa versão do IE9 serve para que sejam testados os novos recursos a fim de encontrar os “bugs” e erros enquanto o navegador ainda está sendo desenvolvido. Por isso mesmo existe um sistema de “feedback”, para que as pessoas possam detalhar os problemas encontrados enquanto navegam.
Por isso é bom reforçar para os internautas comuns que por ser uma versão incompleta, o Internet Explorer 9 pode não ser ainda a melhor opção para ser usada na sua rotina da internet.
Para saber mais leia a matéria completa e baixe a versão preview aqui
Pesquisando e Listando arquivos do disco
protected void Page_Load(object sender, EventArgs e)
{
ListaArquivos(@"d:\", ".jpg", SearchOption.TopDirectoryOnly);
}
private void ListaArquivos(string folder, string extension, SearchOption option)
{
var query = from files in Directory.GetFiles(folder, "*.*", option)
let file = new FileInfo(files)
where file.Extension == extension
select files;
foreach (var item in query)
{
lstBoxFiles.Items.Add(item);
}
}
Recuperando os itens de um ListBox
Adicione o código abaixo no arquivo *.aspx
<asp:ListBox ID="ListBox1" runat="server" SelectionMode="Multiple">
<asp:ListItem Value="Minas Gerais" Selected="True" />
<asp:ListItem Value="São Paulo" />
<asp:ListItem Value="Rio de Janeiro" />
<asp:ListItem Value="Bahia" Selected="True" />
<asp:ListItem Value="Ceará" />
</asp:ListBox>
<br />
<asp:Button ID="btnSel" runat="server" Text="Recuperar" onclick="btnSel_Click" />
Adicione o código baixo no arquivo *.cs
protected void btnSel_Click(object sender, EventArgs e)
{
var selItems = from ListItem li in ListBox1.Items
where li.Selected == true
select li.Text;
Response.Write("Itens selecionado(s): <br />");
foreach (var item in selItems)
{
Response.Write(item.ToString() + "<br />");
}
}
Ordenar os itens de um DropDown
Arquivo *.aspx
<div>
<asp:DropDownList ID="DropDownList1" runat="server">
<asp:ListItem Text="Item 3"></asp:ListItem>
<asp:ListItem Text="Item 1"></asp:ListItem>
<asp:ListItem Text="Item 4"></asp:ListItem>
<asp:ListItem Text="Item 5"></asp:ListItem>
<asp:ListItem Text="Item 2"></asp:ListItem>
</asp:DropDownList>
<br />
<asp:Button ID="btnSort" runat="server" Text="Ordenar" onclick="btnSort_Click"/>
</div>
Arquivo *.cs
protected void btnSort_Click(object sender, EventArgs e)
{
List<string> listItems = DropDownList1.Items.Cast<ListItem>().Select(item => item.Text).ToList();
listItems.Sort((a, b) => string.Compare(a, b));
DropDownList1.DataSource = listItems;
DropDownList1.DataBind();
}
Olha eu aqui de novo, mas dessa vez vou falar de algo muito sério.
Alguém já parou pra pensar quantos “ifs” escrevemos em nossos códigos?
E qual é o impacto disso em nossa aplicação?
Bem, acho que 101% de nós sempre dá um “jeitinho” de esconder aquele problema com um “ifizinho”, pois é, aquele “if” colocado de maneira equivocada, mesmo que seja pra resolver um pequeno problema temporário, pode nos levar a muitas noites sem dormir.
Então, para tentarmos acabar com isso, trago até vocês a “Campanha Anti If”!!
Espero que todos se juntem a nós em prol de melhores códigos e boas práticas!
Nos vemos lá!
Todos nós já passamos por momentos no qual sabíamos que pouparíamos muita dor de cabeça se tivéssemos pensado melhor no que fazer antes de colocarmos a mão na massa.
Existe um velho ditado popular que diz: “quem não tem cabeça tem que ter perna” e basicamente boa parte das pessoas, sejam elas programadores, analista, administradores ou arquitetos já fizeram algo desta forma, muita das vezes por pressão de um diretor ou até mesmo de um cliente.
Bem, veremos então alguns itens que nos ajudarão a responder esta pergunta “Planejar pra quê?”
1º – Para identificarmos a necessidade, ou seja, o que fazer.
Se não identificamos, estaremos dando “tiro pra tudo que é lado” querendo acertar diversos alvos e acabamos, na maioria das vezes, não acertando nada. E como cada tentativa gera gastos, não somente financeiros, mas também nosso tempo e até mesmo a paciência de nossos clientes, devemos planejar. A definição do que fazer é a fixação dos objetivos que poderão ser desenvolvidos em um planejamento.
2º – Para definirmos prioridades, ou seja, por que fazer.
Mesmo organizando e definindo o que precisa ser feito, devemos planejar para verificar quais serão nossas prioridades. Precisamos identificar a ordem da busca dos objetivos a serem desenvolvidos para que estes não virem bagunça.
Mas então, por que fazer? A resposta a esta pergunta é que devemos encontrar uma justificativa para a priorização dos objetivos em termo de gravidade, urgência e tendência, conhecemos como matriz GUT.
Gravidade – é o que inspira risco, cuidado, perigo para quem esta planejando no momento;
Urgência – é a ordem lógica de priorização de implantação, onde verificamos o que deve ser colocado em prática antes;
Tendência – é o que pode se tornar mais grave.
3º – Para estabelecermos metas, ou seja, quando fazer.
Mesmo tendo identificado a ordem de priorização dos objetivos a serem seguidos temos que planejar para definir claramente os prazos de implantação. Esta parte conhecemos como “Cronograma”
Sem metas definidas, nossos objetivos tendem a serem “empurrados com a barriga”. Por isso é muito importante que sejam definidos os prazos de cada objetivo, no caso, até quando eles devem ser alcançados.
4º – Para definirmos estratégias e ações, ou seja, como fazer.
É basicamente agora que a atividade de planejamento estará começando. Planejar é também definir como alcançar objetivos, ou seja, estabelecer estratégias e ações a serem implantadas para cada objetivo desenvolvido. Chamamos isso de “como fazer”.
Mas ai você deve estar se perguntando, qual a diferença entre estratégia e ação? Na prática, esta diferença esta somente na ordem de detalhamento e implementação. Um conjunto de ações forma uma estratégia e um conjunto de estratégia forma o caminho para se atingir um objetivo, ou seja, caímos no velho ditado de Júlio César “dividir para conquistar”.
5º – Para estabelecermos responsabilidades – quem fará.
Não adianta apenas planejarmos, temos também que definir quem irá executar as ações, os objetivos e o plano como um todo. Nesta paste vemos que é a função organização entrando em ação. Temos que ter em mente que tudo deve ser amplamente dividido e delgado para não “abraçarmos o mundo”.
6º – Para delinearmos custos – qual custo.
Muitas vezes não levamos em consideração os custos, isso é um erro comum, por isso não podemos deixar essa tarefa de lado, devemos delinear os recursos humanos, materiais e financeiros que serão desprendidos para que seja realizada cada uma das ações. Com isto conseguimos um controle da situação no que diz respeito aos gastos no projeto. Teremos o custo de cada ação, cada estratégia, cada objetivo e no final o custo total. Não podemos deixar de lado a preocupação com os custos, caso contrário, corremos o risco de não termos recursos suficientes antes mesmo de finalizarmos o projeto.
7º – Para executarmos e acompanharmos.
Não basta termos tudo devidamente planejado, organizado, delegado e calculado, se não realizarmos a execução de tudo. Devemos colocar a execução do projeto em prática e ao mesmo tempo acompanhar todas as mudanças, ações e objetivos que foram traçados, assim teremos certeza que tudo está se desenrolando conforme o planejado.
O planejamento nos ajuda a ter controle da situação, com ele temos capacidade para tomarmos decisões mais precisas e com maior embasamento, pois foi feita toda uma análise e definição de tudo que deve ser feito para que nosso objetivo seja alcançado.
Vimos que “planejar” vai muito além do que muita gente pensa. Então, antes de “colocar a mão na massa”, planeje, este não será um tempo jogado fora pode ter certeza disso!