Criando Mockups com o Microsoft SketchFlow
Mock-up é uma maquete ou um modelo em tamanho real de um projeto. Utilizado para o ensino, demonstração, avaliação de concepção e outras finalidades. Um Mock-up é um protótipo e mostra pelo menos alguma funcionalidade que o projeto real visa ter.
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.
 |
|
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.
Visual Studio 2010 WallPapers
Diversos papéis de parede do Visual Studio 2010. Muito legal! Clique aqui para fazer o download.
Colisões de Nomes
A algum tempo atrás, a comunidade J2EE [Alur et al.] estava usando o termo “VO” (Value Object) para significar um “DTO” (Data Transfer Object), o que causou uma tempestade em um copo d’água na comunidade de padrões. Esta é apenas uma daquelas colisões sobre nomes que acontecem o tempo todo neste negócio. Por volta de 2004 [Alur et al.] decidiram usar o termo Transfer Object.
Objetos de Valor ou Value Objects famosos VO’s
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 And Inversion of Control Container
Inversão de Controle é um princípio usado por frameworks como uma forma de permitir os desenvolvedores estenderem ou criarem aplicações. A idéia básica é que o framework conhece os objetos do programador e faz chamadas sobre eles. Este é o oposto de usar uma API, onde o código do desenvolvedor faz chamadas ao código da API. Assim os frameworks invertem o controle, eles fazem chamadas aos objetos do programador com base em alguns estímulos. O padrão Template Method “Não me ligue eu ligo para você” funciona desta maneira.
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.
Falando de Desempenho
Esses dias lendo o livro do Fowler (PoEAA), ele comenta um pouco sobre desempenho e como muitos dos termos de desempenho são usados de forma inconsistente. Para melhorar a comunicação de equipes de desenvolvimento de software resolvi publicar alguns termos e seus respectivos significados.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 é o Silverlight
Silverlight é um plugin multibrowser e multiplataforma para o desenvolvimento de aplicações RIA e para facilitar a integração com media. Ele reuniu as capacidades de aplicações desktop, aplicações web, funcionalidades do servidor e do cliente, desenvolvimento com linguagens scripts ou orientada a objetos.
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:
Experience IIS Smooth Streaming
Mais exemplos em http://www.silverlight.net/community/samples/silverlight-samples/.
Alguns problemas decorrentes do desenvolvimento tradicional de software e a solução orientada a objetos. A essência da mudança de paradigma.
Segundo Fowler (PoEAA), a noção de camadas tornou-se mais visível nos anos 90, com o surgimento dos sistemas cliente-servidores. Estes eram sistemas em duas camadas: O cliente era a interface de usuário com algum código e o servidor era normalmente algum sistema gerenciador de banco de dados relacional. Ferramentas comuns utilizadas para o desenvolvimento do cliente eram: VB, Powerbuilder e Delphi. Essas ferramentas tornam fácil o desenvolvimento de aplicações que fazem uso intensivo de dados, uma vez que elas disponibilizam componentes visuais que trabalham com SQL. Assim, você pode criar uma tela arrastando controles para um formulário e alterar as suas propriedades para conectar a um banco de dados.
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.
| Camada | Responsabilidades |
| Apresentação | Fornecimento de serviços, exibição de informações (p. ex., em Windows ou Html, tratamento de solicitações do usuário (cliques com o mouse, pressionamento de teclas), requisições HTTP, chamadas em linhas de comando) |
| Domínio | Lógica do real propósito do sistema |
| Fonte de Dados | Comunicação com os bancos de dados, sistemas de menssagens, etc… |
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.
Criando a Sua Primeira Aplicação em Silverlight
Para começarmos você vai precisar ter instalado em sua máquina o Microsoft Visual Studio 2010. Neste artigo estarei utilizando a versão Premium, precisaremos também do Microsoft Silverlight 4 Tools for Visual Studio 2010 que é um pré requisito para desenvolver aplicações em Silverlight 4 e aplicações Ria Services através do Visual Studio 2010. Precisaremos também do Microsoft Expression Blend® 4 Release Candidate (RC).
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:
<UserControl x:Class="FirstSilverlightApplication.MainPage"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
mc:Ignorable="d"
d:DesignHeight="328" d:DesignWidth="400" xmlns:sdk="http://schemas.microsoft.com/winfx/2006/xaml/presentation/sdk">
<Grid x:Name="LayoutRoot" Background="White">
<TextBlock Height="28" HorizontalAlignment="Left" Margin="12,12,0,0" VerticalAlignment="Top" Width="120" Text="Contatos" FontSize="14" FontWeight="Bold" />
<Border BorderBrush="Silver" BorderThickness="1" Height="252" HorizontalAlignment="Left" Margin="12,36,0,0" Name="border1" VerticalAlignment="Top" Width="376" CornerRadius="5">
<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>
</Border>
<Button Content="Cancelar" Height="23" HorizontalAlignment="Left" Margin="93,294,0,0" Name="btnCancelar" VerticalAlignment="Top" Width="75" />
<Button Content="Salvar" Height="23" HorizontalAlignment="Left" Margin="12,294,0,0" Name="btnSalvar" VerticalAlignment="Top" Width="75" />
</Grid>
</UserControl>
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!
Iniciando o C#
Dizem que o C# é um C++ limpo, além disso ele tem várias semelhanças com o JAVA. O C# pronúncia-se “C-Sharp”.
|
Semelhanças entre C# e Java
|
|
| Característica | Implementação |
|
Inspirado no C/C++ |
Boa parte da sintaxe de ambas as linguagens foi inspirada no C/C++, especialmente declaração de variáveis, funções e estruturas de controle. |
|
Orientação a objetos |
Ambas as linguagens suportam conceitos de programação orientada a objetos com a palavra reservada class. |
|
Herança |
Herança simples de classes a partir de ancestral comum e herança múltipla de interfaces. |
|
Gerenciamento de memória |
Automático, com “coletor de lixo”. |
|
Tipagem forte |
Todas as atribuições tem os tipos validados. Os “casts” são sempre verificados em tempo de execução. Não é possível violar o sistema de tipos. |
|
Compila para código intermediário |
Sim. No caso da Microsoft compila para “Intermediate Language” e no Java para “bytecode”. |
|
Tratamento de erro |
Exceptions. |
|
Reflections |
Ambas as linguagens suportam “reflections”. |
|
Unicode |
Ambas as linguagens usam o padrão Unicode para representar caracteres e strings. |
|
Classe que não pode ser herdada |
“final” em Java; “sealed” em C#. |
|
Campo constante |
“static final” em Java; “const” em C#. |
|
Operador que verifica compatibilidade de tipos |
“instanceof” em Java; “is” em C#. |
Novidades do C#
O C# tem diversas novidades que tornam o desenvolvimento de software mais fácil e produtivo, como mostrado a seguir:
| Recursos novos no C#
|
||
| Característica | Java | C# |
|
Compilado para código nativo |
Raramente. O Java é quase sempre interpretado. |
Sempre compilado para código nativo. A compilação pode ser feita na instalação ou na primeira execução do programa. |
|
Todos os tipos derivados de ancestral comum |
Não. |
Sim, todos os tipos são derivados de object. |
|
“Boxing” e “Unboxing” – conversão de tipos por valor para tipos por referência |
Não. Exige conversão manual. |
Sim. |
|
Structs |
Não. |
Sim. |
|
Enum |
Não. |
Sim. |
|
Passagem de parâmetros por referência |
Não. |
Sim, de duas maneiras: ref para parâmetros de entrada e saída e out para parâmetro apenas de saída. |
|
Propriedades |
Não. Podem ser simuladas com métodos Get/Set, com alguma dificuldade. |
Sim, diretamente. A criação de “componentes” é bastante facilitada. |
|
Eventos e Delegates |
Não, categoricamente (veja link abaixo). |
Sim. Um “delegate” é um “ponteiro de função orientado a objetos”, permitindo a associação de um evento de uma classe ao código de outra de maneira conceitualmente simples e poderosa. |
|
Atributos |
Não. |
Sim, permitindo “etiquetar” o código com características que são interrogadas em tempo de execução através de “reflection”. |
|
Ponteiros |
Não suportado diretamente, apenas indiretamente através de “referências”. |
A princípio suporta referências, mas os ponteiros podem ser usados em código “inseguro” por questões de performance ou compatibilidade com DLLs. |
|
Sobrecarga de operadores |
Não. |
Sim. |
|
Operadores de conversão |
Não. |
Sim. |
|
Operadores de cast |
Um, sintaxe semelhante ao C/C++. |
Dois, um semelhante ao C/C++ e o outro “as”. Um retorna null e outro dispara exception em casso de erro de conversão. |
|
Inteiros sem sinal |
Não. |
Sim. |
|
Tipo numérico pouco sujeito a erros de representação e arredondamento |
Não. |
Sim, o tipo decimal pode ser usado em softwares que não toleram facilmente erros de arredondamento, como programas de contabilidade |
|
Forech: loop para varrer arrays e coleções |
Não. |
Sim. |
|
Campo readonly |
Não. |
Sim. |
|
Documentação integrada em XML |
Não. |
Sim, permitindo que o programador escreva facilmente a documentação enquanto programa. Este documentação pode depois ser extraída do fonte ou usada no próprio ambiente de desenvolvimento. |
| Switch com strings |
Não. |
Sim, facilitando o desenvolvimento. |
|
Controle sobre “estouro de faixa” numérica |
Não. |
Sim. As palavras reservadas checked e unchecked permitem mudar o que o programa faz quando há um “estouro de faixa numérica”: o checked dispara uma exception; o unchecked não. |
|
Funções com número variável de parâmetros |
Não. |
Sim, de forma “tipada”, com a palavra reservada params. |
|
Formas do método Main |
Uma. |
Quatro. O main pode aceitar um array de strings ou nada; pode retornar inteiro ou nada. |
|
Goto |
Não. |
Sim, com a restrição de que não pode entrar em um bloco. |
|
Arquivo “executável” independente do namespace |
Um “package” Java obrigatoriamente está associado a um único arquivo “.class”. |
Não existe relação direta entre o “namespace” e a DLL que o implementa, dando mais flexibilidade ao desenvolvedor na hora de quebrar seus projetos em pedaços menores. |
|
Especificadores de acesso |
Quatro. |
Cinco. O internal, adicional, especifica acesso apenas no mesmo “assembly” (mesma DLL, a grosso modo). |
|
Diretivas de compilação condicional (#ifdef etc) |
Não. |
Sim. |
|
Destrutores |
Não, mas o método Finalize pode ser usado. |
Sim. |
|
Padronização por algum organismo internacional |
Não. Duas submissões da Sun foram posteriormente retiradas. |
Sim. Submetido e aceito pelo ECMA (http://www.ecma.ch). |
|
Chama APIs do Windows e DLLs |
Não. Mesmo o suporte “nativo” de alguns compiladores é extremamente limitado pela falta de ponteiros na linguagem. |
Sim. |
|
Chama objetos COM/COM+ |
Não. |
Sim. |
|
Cria objetos COM/COM+ |
Não. |
Sim. |
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
