O SketchFlow é um recurso da família Microsot Expression Studio Ultimate, que lhe da a capacidade, rapidez e eficácia de mapear o fluxo de uma aplicação de interface com o usuário através de layout de telas permitindo a transição de um estado para outro. Esta habilidade permite explorar e testar várias idéias sem investir grandes quantidades de tempo, mostrando ao seus clientes que você é capaz de encontrar a solução certa para eles.

Com o SketchFlow os clientes podem testar diversos cenários e fornecer um feedback para a equipe de desenvolvimento, através de comentários, anotando a sua experiência enquanto navegam pelo protótipo.

Então vamos começar!!!

Um cliente te ligou solicitando a criação de uma tela para a consulta de pedidos de compra feitos no dia que deve mostrar o número de vendas/hora por vendedor. Você logo imaginou o que o cliente queria e iniciou o desenvolvimento do protótipo de tela.

Para isso inicie o Microsoft Expression Blend 4 + Skecth Flow e na guia Projects escolha New Project, e então na tela New Project escolha Silverlight SketchFlow Application e nomeie o protótipo com o  seguinte nome PurchaseRequestSample então click em OK, conforme a figura 1 logo abaixo.

Figura 1 – Criando o projeto para o protótipo da tela.

Na barra de ferramentas do blend clique em Assets (recursos) e então na árvore selecione SketchFlow –> Styles –> SketchStyles clique no controle TitleLeft-Sketch e então desenhe no topo da página. Com um duplo clique no controle você poderá editar o texto ou então utlizar a barra de propriedades no grupo Common Properties propriedade Text.

Figura 2 – Selecionando o controle.

Figura 3 – Controle desenhado no topo da página.

Figura 4 – Barra de propriedades.

Existem algumas coisas importantes que você precisa saber ao utilizar o Expression Blend.

Utilize essa seta, quando você quiser redimensionar os controles. Quando o controle estiver selecionado ele ficará de forma parecida como o da imagem abaixo, mostrando as áreas em que você pode manipular o mouse para redimensionar o controle. Podemos também manipular as âncoras do controle. Quando a âncora está habilitada ela fica dessa forma  e quando desabilitada dessa . Quando habilitada; a medida em que a página for redimensionada o controle também será. Isso depende das configurações de âncora que você definiu, nesse caso o controle é redimensionado quando todas as âncoras estão habilitadas. Para habilitar ou desabilitar as âncoras basta dar um clique em cima dela. Utilize essa seta, quando você quiser mover os controles. Utilize a “Mãozinha” para mover a página dentro do Expression Blend sem desorganizar os controles. Utilize a Lupa para aumentar o zoom da página. Mantenha a tecla ALT pressionada enquanto clica para reduzir o zoom. Utilize para inserir textos na página. BasicTextBlock-Sketch para Labels e BasicTextBox-Sketch para caixas de texto. Utilize para inserir controles de usuário como botões, caixas de seleção, etc…

Agora, vamos criar um subtítulo para a tela, para isso em Assets –> Sketch Styles selecione SubtitleLeft-Sketch e adicione o controle logo abaixo do título,  então altere o texto para “Vendas hora por vendedor”. Você pode encontrar os controles facilmente fazendo buscas conforme a figura 5.

Figura 5 – Localizando os controles mais facilmente.

Mude o tamanho da fonte do controle para 14, através da barra de propriedades conforme a figura  6.

Figura 6 – Mudando o tamanho da fonte

Agora vamos inserir um retangulo abaixo do subtítulo para simular uma caixa de listagem, para isso pesquise em Assets por rect para localizar o controle Rectangle-Sketch.

A sua página deverá ficar como a figura 7 ao executar o protótipo. Para executar o protótipo pressione a tecla F5 ou vá para o menu Project e clique na opção Run Project .

Figura 7 – Página esperada até o momento.

Em algum momento teremos de redimensionar a página que está sendo criada. Uma coisa que você precisa saber é que toda a página ou UserControl criado pelo Expression Blend por padrão tem um controle Grid nomeado de LayoutRoot é nele que adicionamos os nossos controles. Através da barra de ferramentas Objects and Timeline podemos observar como os nosso controles estão organizados. Veja a figura 8.

Figura 8 – Objects and Timeline

Todos os controles que estão no UserControl podem ser observados através dessa barra de ferramenta. Cada controle possui um símbolo de um olho , clique nele para ocultar ou mostrar os controles que estão na página. Você também pode travar os controles evitando que eles se movam acidentalmente, para isso clique ao lado do símbolo do olho para habilitar o cadeado.

Figura 9 – TextBlock Travado.

O controle Grid “LayoutRoot” é redimensionado junto com a página, pois todas as suas âncoras estão habilitadas por padrão. Como queremos aumentar a página devemos clicar em UserControl na barra Objects and Timeline e então clicar na seta de redimensionamento e redimensionar a página conforme o desejado.

Quando estamos redimensionando a página podemos notar que os controles acompanham o redimensionamento do controle pai. Caso você não queira que eles acompanhem desabilite as âncoras.

Agora vamos inserir alguns retângulos dentro do rentâgulo criado anteriormente e dentro de cada retângulo adicione um controle BasicTextBlock-Sketch com o nome do vendedor.

Figura 10 – Selecionando o controle BasicTextBlock-Sketch

Deixe o nome dos vendedores em negrito selecionando B “Bold” através da barra de propriedades no grupo Text.

Figura 11

A página deverá ficar conforme a figura 12.

Figura 12

Vamos redimensionar a página e adicionar mais controles até que ela fique da seguinte forma.

Figura 13

As setas do lado direito foram desenhas através dos controles Block Arrow Down Sketch e Block Arrow Up Sketch, elas foram redimensionadas até que ficassem dessa forma.

As cores dos retângulos foram aplicadas através do grupo Brushes da barra de propriedades, selecionando Background e aplicando a cor desejada.

Figura 14

Nesse post conhecemos o SketchFlow e aprendemos diversos detalhes do Expression Blend. Aprendemos como adicionar controles a página, redimensioná-los e alterar suas propriedades.

No próximo post adicionaremos fluxos de navegação a esse protótipo, e será demonstrado como o cliente pode fornecer um feedback para a equipe de desenvolvimento.

Veja o protótipo desse post clicando aqui ou um mais completo aqui.

Continue acompanhando novidades através do blog da FlexDev.

Um objeto que representa um aspecto descritivo do domínio sem nenhuma identidade conceitual é chamado de OBJETO DE VALOR. OBJETOS DE VALOR são instanciados para representar elementos do design com os quais só nos preocupamos pelo que eles são, e não quem ou quais são.

Quando uma criança está desenhando, ela está preocupada com a cor do lápis que vai escolher, e pode estar preocupada com a espessura da ponta. Mas se houver dois lápis da mesma cor e de mesmo formato, ela provavelmente não vai se importar em qual deles está utilizando. Se um lápis se perder e for substituído por outro da mesma cor, ela pode recomeçar o seu trabalho sem se preocupar com a troca.

Pergunte a uma criança sobre vários desenhos exibidos em uma escola, e ela rapidamente vai distinguir aqueles que ela fez dos que foram feitos por outros alunos. Os desenhos dos alunos possuem identidades úteis. Mas imagine como seria para uma criança ter que rastrear quais linhas de desenho foram feitas por cada lápis. Desenhar já não seria uma diversão para as crianças.

As cores são um exemplo de OBJETO DE VALOR, assim também são as strings e os números. (Você não se importa com qual “4” ou qual “Q” você tem). Esses exemplos básicos são simples, mas OBJETOS DE VALOR não são necessariamente simples.

Objetos de valor normalmente são transmitidos como parâmetros em menssagens entre objetos. Eles são freqüentemente transitórios, criados por uma operação e em seguida descartados. Objetos de valor são usados como atributos de ENTIDADES (e outros VALORES).

Figura 1. A vigência é um atributo do contrato e é um objeto de valor.

Os atributos que formam um OBJETO DE VALOR devem formar um todo conceitual. Por exemplo, rua, cidade e código postal não devem ser atributos separados de um objeto Pessoa. Eles fazem parte de um único endereço completo, que torna uma Pessoa mais simples e um OBJETO DE VALOR mais coerente.

Figura 2. Um OBJETO DE VALOR pode fornecer mais informações sobre uma ENTIDADE. Ele deve ser conceitualmente completo.

Endereço é OBJETO DE VALOR? Quem está perguntando?

Em um software para uma empresa de compras via correio, é necessário ter o endereço para a confirmar o cartão de crédito, e para endereçar a encomenda. Mas se um colega que divide o apartamento com uma pessoa também fizer o pedido na mesma empresa, não é importante saber se eles estão na mesma localização. O endereço é um OBJETO DE VALOR.

Em um software para os correios, com o intuito de organizar as rotas de entrega, o país poderia ser formado em uma hierarquia de regiões, cidades, regiões postais e quarteirões, terminando no endereço da pessoa. Esses objetos de endereço receberiam seus códigos postais de seus geradores na hierarquia, e se o serviço de correio decidisse redesignar as regiões postais, todos os endereços daquela faixa entrariam no mesmo barco. Aqui o Endereço é ume ENTIDADE.

Em um software para uma empresa prestadora de serviços de eletricidade, um endereço corresponde a um destino para as linhas e serviços da empresa. Se duas pessoas que dividem o mesmo apartamento telefonassem para solicitar um serviço de conserto na parte elétrica, a empresa precisaria perceber isto.  O Endereço é uma ENTIDADE. Outra opção é que o modelo poderia associar o serviço da prestadora com uma “residência”, uma ENTIDADE com um atributo endereço. Neste caso o Endereço seria um OBJETO DE VALOR.

Este post é um esboço sobre Domain Driven Design.

Inversion of Control Container Possibilita a criação e destruição dos objetos, fornecendo  todas as dependências e configurações exigidas por uma classe. Desta maneira não é preciso obter e configurar as classes da qual uma classe depende. Isso reduz drasticamente o acoplamento de um sistema e como consequência facilita a reutilização e a testabilidade.

Existe uma confusão criada por pessoas que pensam que "Inversão de Controle"é um sinônimo de "Inversão de Controle de Contêineres. Como foi dito, Inversão de controle é um princípio mais amplo.

1. Tempo de Resposta
   

   É a quantidade de tempo que o sistema leva para processar uma solicitação externa. Pode ser uma ação na interface com o usuário, como o pressionamento de um botão, ou uma chamada de API do servidor.

2. Agilidade de Resposta
   

   A agilidade de resposta diz respeito ao quão rapidamente o sistema reconhece uma solicitação (em oposição ao tempo que leva para processá-la). Isso é importante em muitos sistemas porque os usuários podem ficar frustrados se um sistema demorar para responder a uma solicitação, ainda que seu tempo de resposta seja bom. Se o seu sistema esperar durante toda uma solicitação, então sua agilidade de resposta e o seu tempo de resposta são os mesmos. Entretanto se você indicar que recebeu a solicitação antes de completá-la, então sua agilidade de resposta é melhor.

3. Latência
   

   É o tempo mínimo requerido para obter qualquer forma de resposta, mesmo se não houver nenhum trabalho a fazer. Se eu pedir a um programa para não fazer nada, então devo receber uma resposta quase instantânea se o programa rodar na minha máquina local. Entretanto, se o programa rodar em um computador remoto, pode demorar alguns segundos devido ao tempo gasto para que a solicitação e a resposta cheguem a seu destino através da conexão. Como desenvolvedor de aplicações, geralmente, nada posso fazer para melhorar a latência. A latência é o motivo pelo qual devemos minimizar chamadas remotas.

4. Throughput
   

   É a quantidade de coisas que você pode fazer em uma dada quantidade de tempo. Se você estiver contabilizando o tempo gasto na cópia de um arquivo, o throughput poderia ser medido em bytes por segundo. Para aplicações corporativas, ume medida típica é o número de transações por segundo (tps), mas o problema é que isso depende da complexidade da sua transação.

   Nesta terminologia, desempenho pode significar tanto throughput quanto tempo de resposta – o que for mais importante para você. Às vezes, pode ser difícil falar sobre desempenho quando uma técnica melhora o throughput, mas piora o tempo de resposta. Assim é melhor usar o termo mais preciso. Da perspectiva de um usuário a agilidade de resposta em detrimento do tempo de resposta ou do throughput aumentará o desempenho.

5. Carga
   

   A carga é uma medida da pressão a que o sistema está submetido, que poderia ser medida pelo número de usuários a ele conectados em um determinado instante de tempo. A carga é geralmente um contexto para alguma outra medida, como um tempo de resposta. Assim, você pode dizer que o tempo de resposta para alguma solicitação é de 0,5 segundo com 10 usuários e de 2 segundos com 20 usuários.

6. Sensibilidade de carga
   

   É uma medida de como o tempo de resposta varia com a carga. Digamos que o sistema A tenha um tempo de resposta de 0,5 segundo para um número de usuários entre 10 e 20, e o sistema B tenha um tempo de resposta de 0,2 segundo para 10 usuários que aumenta para 2 segundos com 20 usuários. Neste caso o sistema A tem uma sensibilidade de carga menor do que o sistema B.

7. Eficiência
   

   A eficiência é o desempenho dividido pelos recursos. Um sistema que obtenha 30 tps com duas CPUs é mais eficiente que uma que obtenha 40 tps com quatro CPUs idênticas.

8. Capacidade
   

   A capacidade de um sistema é uma indicação do máximo throughput efetivo ou máxima carga efetiva. Este poderia ser um máximo absoluto ou um ponto a partir do qual o desempenho caia abaixo de um limite aceitável.

9. Escalabilidade

A escalabilidade é ume medida de como o acréscimo de recursos (normalmente hardware) afeta o desempenho. Um sistema escalável é aquele que lhe permite adicionar hardware e obter uma melhora de desempenho proporcional, como dobrar o número de servidores disponíveis para dobrar o throughput. A escalabilidade vertical, ou escalar para cima, significa adicionar mais poder a um único servidor (por exemplo, acrescentar memória). A escalabilidade horizontal, ou escalar para fora, significa adicionar mais servidores.

O problema aqui é que as decisões de projeto não afetam todos esses fatores de desempenho de forma igual. Digamos que temos dois sistemas de software rodando em um servidor: a capacidade do Peixe-Espada é de 20 tps, enquanto a do Camelo é de 40 tps. Qual dos dois tem melhor desempenho? Qual é mais escalável? Não podemos responder a questão de escalabilidade com estes dados, e a única coisa que podemos dizer é que o Camelo é mais eficiente em um único servidor. Se adicionarmos outro servidor, percebemos que o Peixe-Espada agora trata 35 tps, e o camelo 50 tps. A capacidade do Camelo ainda é melhor, mas parece que o Peixe-Espada pode ter melhor escalabilidade. Se continuarmos adicionando servidores, descobriremos que o Peixe-Espada obtém 15 tps por servidor adicional e que o Camelo obtém 10. Com esses dados, podemos dizer que o Peixe-Espada tem uma melhor escalabilidade horizontal, ainda que o Camelo seja mais eficiente com menos de cinco servidores.

Os projetistas muitas vezes fazem coisas complicadas que aumentam a capacidade de uma plataforma específica de hardware quando, em verdade, poderia ser mais barato comprar mais hardwares. Se o Camelo tem um custo maior do que o Peixe-Espada, e esse custo maior é equivalente a um par de servidores, então o Peixe-Espada acaba sendo mais barato, mesmo se você precisar de apenas 40 tps. Está na moda reclamar por ter que depender de hardware melhor para fazer o nosso software rodar apropriadamente. No entanto, adquirir hardware mais novo é com freqüência mais barato do que fazer o software rodar em sistemas menos poderosos. De forma semelhante, adicionar mais servidores é freqüentemente mais barato do que adicionar mais programadores – desde que o sistema seja escalável.

O que devemos ter em mente é que o Silverlight é mais do que simplesmente um container para executar aplicações ricas e interativas na web. O silverlight é uma plataforma para desenvolvimento de aplicações, cross-plataforma e cross-browser.

No silverlight o conteúdo é declarado utilizando o XAML. O XAML é um arquivo XML onde é possível declarar elementos visuais da interface, incluindo animações.

O Silverlight contém um subset do .Net Framework que inclui bibliotecas e componentes para integração de dados, networking, controles WPF e CLR (Common Language Runtime). Isso permite que desenvolvamos as nossas aplicações utilizando as linguagens mais comuns em .Net, VB.Net e C#, compiladas.

Não é necessário ter o .Net Framework instalado no cliente ou no servidor. Apenas o plug-in do silverlight é necessário.

Para mais informações sobre Rich Internet Application, veja: http://en.wikipedia.org/wiki/Rich_Internet_application

Exemplos de aplicações em silverlight:

HARD ROCK – MEMORABILIA

 Calculadora interessante…

 Microsoft Health

Experience IIS Smooth Streaming

 Out of Browser

Mais exemplos em http://www.silverlight.net/community/samples/silverlight-samples/.

Se a aplicação tem que exibir e fazer atualizações simples nos dados relacionais, então esse sistema cliente-servidor funciona muito bem. Porém o problema surge com a lógica de domínio: regras de negócio, validações, cálculos, etc…. Normalmente as pessoas que trabalham com essa arquitetura escrevem a lógica no cliente, embutindo a lógica diretamente nas telas de interface com o usuário. À medida que a lógica do domínio se torna mais complexa, fica muito mais difícil trabalhar com esse código.

Embutir a lógica nas telas facilita a duplicação de código, o que significa que alterações simples resultam em busca de código semelhante em muitas telas. Este problema pode, em parte, ser tratado fatorando-se o código comum em sub-rotinas, mas mesmo assim, muito da duplicação é complicada de ser removida e mais difícil ainda de ser localizada. A aplicação resultante pode acabar sendo uma teia confusa de sub-rotinas sem uma estrutura clara. Uma alternativa é colocar a lógica de domínio no banco de dados na forma de procedimentos armazenados (Store Procedures). Estes, no entanto fornecem mecanismos limitados de estruturação, o que leva mais uma vez a código confuso. Muitas pessoas gostam de bancos de dados relacionais porque SQL é um padrão, o que lhes permite a qualquer momento mudar de fornecedor de banco de dados. Ainda que poucas pessoas realmente fizessem isso, muitas gostariam de ter a opção de mudar de fornecedor sem que isso implicasse em custo de migração alto demais. Por a maioria dos sistemas gerenciadores de banco de dados ser proprietária os procedimentos armazenados eliminam essa opção.

Ao mesmo tempo em que a arquitetura cliente-servidor estava ganhando popularidade, o mundo orientado a objetos estava ascendendo. A comunidade orientada a objetos tinha a resposta para o problema da lógica de domínio: migrar para um sistema de três camadas. Nesta abordagem você tem a camada de apresentação a sua interface com o usuário, uma camada de domínio para a sua lógica de domínio e uma camada de dados. Desta maneira, você pode tirar toda a complexa lógica de domínio da interface com o usuário e colocá-la em uma camada na qual você pode estruturá-la apropriadamente utilizando objetos. Embora a abordagem de três camadas tivesse muitos benefícios, as ferramentas para o desenvolvimento cliente-servidor eram convincentes se o seu problema fosse simples. A verdade é que muitos sistemas eram simples, ou pelo menos começavam simples. Além disso, as ferramentas para o desenvolvimento cliente-servidor eram difíceis, ou mesmo impossíveis, de usar em uma configuração de três camadas.

O abalo sísmico foi o advento da Web. De repente as pessoas passaram a querer instalar aplicações cliente-servidor usando um navegador Web. No entanto, se toda a sua lógica de negócio estivesse enterrada em um cliente rico, então toda ela precisaria ser refeita para ter uma interface Web. Um sistema bem projetado em três camadas, poderia simplesmente acrescentar uma nova camada de apresentação e estaria pronto.

Padrões Transaction Script e Domain Model

Usar um Domain Model em Oposição ao Transaction Script é a essência da mudança de paradigma que as pessoas de orientação a objetos tanto falam.

Um Transaction Script é, essencialmente, um procedimento que recebe os dados de entrada da camada de apresentação, efetua o processamento com validações e cálculos, armazena dados no banco de dados e invoca quaisquer operações necessárias em outros sistemas. Talvez ele responda com mais dados para a apresentação, talvez executando mais cálculos para ajudar a formatar a resposta. Assim, podemos pensar nesse padrão como sendo um roteiro para uma ação ou transação de negócio. Ele não tem de ser constituído, necessariamente de um único procedimento. As partes podem ser separadas em sub-rotinas, e estas podem ser compartilhadas por diferentes Transaction Scripts. Entretanto, a motivação ainda é a de um procedimento para cada ação, de modo que um sistema de varejo possa ter Transaction Scripts para a checagem de saída, para acrescentar algo ao carrinho de compras, para mostrar  a situação atual da entrega e assim por diante.

Um Transaction Script oferece diversas vantagens:

• É um modelo procedural simples que a maioria dos desenvolvedores compreende.
• Funciona bem com uma camada de dados simples.
• O modo de estabelecer as fronteiras de transação é uma tarefa óbvia: comece abrindo uma transação e termine fechando-a. É fácil para as ferramentas fazer isso por trás dos panos.

Infelizmente existe muitas desvantagens nesse padrão que tendem a aparecer à medida que a complexidade da lógica de domínio aumenta. Freqüentemente haverá  código duplicado, uma vez que diversas transações precisam fazer coisas parecidas. Como eu já havia citado acima, este problema pode, em parte, ser tratado fatorando-se o código comum em sub-rotinas, mas mesmo assim, muito da duplicação é complicada de ser removida e mais difícil ainda de ser localizada. A aplicação resultante pode acabar sendo uma teia confusa de sub-rotinas sem uma estrutura clara.

É claro que a lógica complexa é o cenário ideal para os objetos, e a maneira pela qual a orientação a objetos lida com este problema é por meio de um Modelo de Domínio (Domain Model).

Com um Domain Model, construímos um modelo do nosso domínio o qual, pelo menos em uma primeira aproximação, é organizado primariamente em torno dos nomes de domínio. Assim um sistema de vendas teria classes para a venda, produto, cliente, assim por diante. A lógica para lidar com validações e cálculos seria colocada neste modelo de domínio, de modo que um objeto venda poderia teria um método para calcular o total da venda, calculando o total de produtos, custo de entrega, etc….

Em vez de uma rotina contendo toda a lógica para uma ação de usuário, cada objeto realiza uma parte da lógica que seja relevante para ele. Se você não estiver acostumado com um Domain Model, aprender a trabalhar com um pode ser muito frustrante quando você começa a correr de objeto em objeto tentando descobrir em qual está o comportamento.

Os custos de um Domain Model decorrem da complexidade de usá-lo e da complexidade da sua camada de dados. Leva tempo para que as pessoas novatas em modelos ricos de objetos se acostumem a um Domain Model rico. Os desenvolvedores freqüentemente precisam gastar diversos meses trabalhando em um projeto que usa este padrão antes que seus paradigmas mudem. No entanto, quando você se acostuma a um Domain Model, geralmente está contagiado para o resto da vida e torna-se fácil trabalhar com ele no futuro – é assim que fanáticos por objetos são criados. No entanto, uma minoria significativa de desenvolvedores parece não ser capaz de dar o salto.

Mesmo depois de ter dado o salto, você ainda tem que lidar com o mapeamento do banco de dados. Quanto mais rico for o seu Domain Model, mais complexo será o mapeamento para um banco de dados relacional. Uma sofisticada camada de dados se aproxima bastante de um custo fixo – obter uma boa camada de dados custa uma quantidade razoável de dinheiro (se você comprar) ou tempo (se você fizer), mas assim que você tiver uma, pode fazer muito com ela.

Quer mais? Leia Patterns of Enterprise Application Architecture – PoEAA.

1. Inicie o Microsoft Visual Studio 2010

2. No menu File passe o mouse sobre New, e então selecione New Project

3. A caixa de diálogo New Project será exibida

4. Em Installed Templates no lado esquerdo da janela selecione Visual C# e então selecione Silverlight. Selecione Silverlight Application e verifique se na caixa de seleção superior está selecionado o .NET Framework 4. Em Name colocaremos o nome de nossa aplicação no caso FirstSilverlightApplication e então click em OK.

5. Na caixa de diálogo New Silverlight Application desselecione Host the Silverlight application in a new Web site e em Silverlight Version verifique se Silverlight 4 está selecionado e então click em OK.

6. Após clicado em OK você terá uma tela como esta.

Criando Controles

Os controles podem ser adicionados a aplicação usando o ToolBox do Visual Studio ou editando o texto XAML diretamente no editor XAML.

1. Selecione o controle TextBlock e o arraste a MainPage.xaml.

A. Altere a propriedade Text do controle para Contatos.

B. Altere o tamanho da fonte do controle para 14, através da propriedade FontSize.

C. Deixe a fonte em negrito através da propriedade FontWeight selecionando Bold.

2. Selecione o controle Border e o arraste a MainPage.xaml, altere a propriedade CornerRadius para 5.

3. Arraste o controle Grid para dentro do controle Border, então resete as propriedades Height e Width do Grid.

4. Arraste controles TextBlock e TextBox para dentro do controle Grid de forma que a página fique conforme a figura abaixo.

Como você já deve ter percebido, todas as mudanças feitas através da ToolBox Properties são refletidas instantaneamente no código XAML. Veja abaixo o código XAML referente ao controles TextBlock e TextBox que adicionamos dentro do grid.

 <Grid>
         <TextBlock Height="20" HorizontalAlignment="Left" Margin="6,9,0,0" VerticalAlignment="Top" Width="74" Text="Nome:" TextAlignment="Right" />
         <TextBox Height="23" HorizontalAlignment="Left" Margin="86,6,0,0" Name="txtNome" VerticalAlignment="Top" Width="282" />
         <TextBlock Text="Empresa:" Height="20" HorizontalAlignment="Left" Margin="6,37,0,0" VerticalAlignment="Top" Width="74" TextAlignment="Right" />
         <TextBlock Text="Cargo:" Height="20" HorizontalAlignment="Left" Margin="6,66,0,0" VerticalAlignment="Top" Width="74" TextAlignment="Right" />
         <TextBlock Text="E-mail:" Height="20" HorizontalAlignment="Left" Margin="6,94,0,0" VerticalAlignment="Top" Width="74" TextAlignment="Right" />
         <TextBlock Text="Telefone:" HorizontalAlignment="Left" Margin="6,123,0,107" Width="74" TextAlignment="Right" />
         <TextBlock Text="Observações:" Height="20" HorizontalAlignment="Left" Margin="0,149,0,0" VerticalAlignment="Top" Width="80" TextAlignment="Right" />
         <TextBox Height="23" HorizontalAlignment="Left" Margin="86,35,0,0" Name="txtEmpresa" VerticalAlignment="Top" Width="282" />
         <TextBox Height="23" HorizontalAlignment="Left" Margin="86,64,0,0" Name="txtCargo" VerticalAlignment="Top" Width="282" />
         <TextBox Height="23" HorizontalAlignment="Left" Margin="86,92,0,0" Name="txtEmail" VerticalAlignment="Top" Width="282" />
         <TextBox Height="23" HorizontalAlignment="Left" Margin="86,121,0,0" Name="txtDDI" VerticalAlignment="Top" Width="41" />
         <TextBox Height="23" HorizontalAlignment="Left" Margin="133,121,0,0" Name="txtDDD" VerticalAlignment="Top" Width="41" />
         <TextBox Height="23" HorizontalAlignment="Left" Margin="180,121,0,0" Name="txtTelefone" VerticalAlignment="Top" Width="188" />
         <TextBox Height="95" HorizontalAlignment="Left" Margin="86,149,0,0" Name="txtObservacoes" VerticalAlignment="Top" Width="282" />
 </Grid>

5. Aumente o tamanho da página “Height” e arraste dois controles Button, botões Salvar e Cancelar. Altere as suas propriedades Content e Name respectivamente.

Imagem da página criada:

Código XAML completo da página:

Nos próximos artigos de Silverlight estaremos complementando essa pequena aplicação, iremos criar o Grid para a listagem de contatos, botões de inclusão, edição e deleção. Utilizaremos WCF para acesso aos dados.

O WCF para quem não conhece é um poderoso framework para a criação de aplicações orientadas a serviço.

Até o próximo artigo!

Novidades do C^#

O C^# tem diversas novidades que tornam o desenvolvimento de software mais fácil e produtivo, como mostrado a seguir:

Existem alguns pontos importantes por trás dos tópicos acima:

O C^# implementa características interessantes do C++ que foram removidas no Java, como passagem de parâmetros por referência, enum, struct, sobrecarga de operadores, operadores de conversão e compilação condicional;

O C^# tem vários recursos que melhoram a performance, como uso de “tipos por valor” (structs e enums) em situações simples onde o uso de uma classe seria muito “caro” e suporte direto a ponteiros;

Suporte direto a componentes, através de a propriedades e eventos;

A unificação do sistema de tipos (tudo é derivado de object) e a conversão de valores para referências através de “boxing” são recursos que, ao mesmo tempo simplificam a programação, como também permitem melhores abstrações;

Boa integração com código anterior escrito para Windows: suporte a ponteiros, chamar DLLs, chamar objetos COM e criar objetos COM. Não é necessário abandonar o C^# para usar alguma facilidade não contemplada pela biblioteca de classes;

Diversos recursos que facilitam a programação, como switch com strings, “loop” foreach para varrer todos os elementos de uma coleção ou array, campo readonly;

Leitura interessante na Web
Introdução ao C^#:
http://msdn.microsoft.com/vstudio/nextgen/technology/csharpintro.asp

Artigo da MSDN Magazine:
http://msdn.microsoft.com/msdnmag/issues/0900/csharp/csharp.asp

Artigo da Doctor Dobb’s Journal sobre C^#:
http://www.ddj.com/articles/2000/0065/0065g/0065g.htm

Site de C^# da O’Reyley, com vários artigos comparativos:
http://www.oreillynet.com/topics/dotnet/csharp.net

Artigo da Sun “explicando” porque o Java não tem nem terá delegates:
http://java.sun.com/docs/white/delegates.html

Resposta da Microsoft mostrando porque os delegates são úteis:
http://msdn.microsoft.com/archive/default.asp?url=/ARCHIVE/en-us/dnarvj/html/msdn_deltruth.asp

Sobre o prêmio da DDJ a Anders Hejlsberg, o criador do C^#:
http://www.ddj.com/articles/2001/0105/0105a/0105a.htm

Entrevista de Anders Hejlsberg:
http://www.dnjonline.com/teched2001/Hejlsberg_head2head.html

Mais uma entrevista com Anders Hejlsberg:
http://news.cnet.com/news/0-1003-200-5677521.html?tag=tp_pr

Coluna fictícia de Anders Hejlsberg:
http://www.ddj.com/columns/stob/2001/0106vs001.htm

Autor: Mauro Sant’Anna