.NET Memory Fragmentation

Olá pessoal,

Gostaria de compartilhar alguns links de materiais que considerei bastante úteis quando tive que identificar problemas de Fragmentação e Falta de Memória em .NET.

Abração,
Paulo Ricardo Stradioti

Design Patters – Singleton

Este post utiliza em seu contexto e exemplos a linguagem de programação C# (CSharp).

O padrão Singleton com certeza é um dos mais conhecidos entre os desenvolvedores. Talvez seja por que ele é relativamente simples, ou, então, por que é muito amado e muito odiado por seus defensores e opositores, respectivamente. Seja como for, é um padrão que tem seu valor e sua utilização dependerá do cenário que você, Arquiteto ou Desenvolvedor, precisa resolver, por isso, não devemos desprezar seu valor.

Continue reading “Design Patters – Singleton”

C# Anti Patterns

Se você já possui algum tempo de experiência como desenvolvedor, deve ter percebido que alguns problemas (requisitos) são muito recorrentes durante o nosso trabalho.

Para citar apenas alguns exemplos, esses problemas vão de garantir que exista apenas uma instância de um determinado recurso no sistema (Singleton Design Pattern), passando pela execução de comandos/ações (Command Design Pattern) e o encapsulamento de um objeto complexo a fim de simplificar o seu uso (ou, então, de um componente que será substituido no futuro) (Proxy Design Pattern). Esses são problemas com os quais nos deparamos quando estamos codificando. Existem alguns problemas que devem ser resolvidos antes mesmo de partimos para o código, por exemplo, como a aplicação será estruturada (Architectural Patterns, ou padrões de Arquitetura, ajudam a resolver esses problemas).

Assim, ao ter que implementar os mesmos requitisos/resolver os mesmos problemas várias e várias vezes, é comum que você caia na repetição (repeat yourself). É exatamente essa repetição que deu origem aos Padrões (Patterns). Entretanto, os Patterns possuem algo de especial, eles não são simplesmente uma maneira repetitiva de resolver um determinado problema, eles são justamente a melhor maneira para se resolver aquele problema. Assim, é coerente dize que para cada um dos problemas recorrentes identificados, existe uma maneira otimal para resolvê-lo e essa menira otimal é o Pattern.

Por outro lado, da mesma forma é possível repetir boas soluções para determinados problemas, também é plausível que sejam repetidos erros ou práticas ruins. Sim, é possível que eu ou você tenhamos cometido o mesmo erro várias e várias vezes.. essa repetição acontece, em geral, até que você descubra que o que você está fazendo ou está errado e introduzirá potenciais bugs no código ou, então, não faz sentido para a linguagem/framework no qual você está trabalhando. Alguns desses erros / práticas sem sentido foram identificadas como sendo praticadas por vários desenvolvedores e, por terem se tornado comuns, receberam o nome de Anti Patterns (Anti Padrões).

É seguro afirmar que a maioria dos Anti Padrões são praticados pelos seguintes motivos:

  • Falta de conhecimento da plataforma/linguagem/framework utilizado
  • Utilização de técnicas defensivas de programação que são utilizadas e fazem sentido em outras linguagens

Se você estiver confuso, dê-me mais alguns parágrafos até examinarmos alguns exemplos, acredito que tudo fica mais claro com a prática.

Antes de examinarmos com mais detalhes alguns exemplos, vejamos algumas características que permitem identificar um Anti Pattern.

  • O código/a prática não resolve o problema
  • O código/a prática falha em algum ou vários cases de extremidade (edge-cases)
  • O código/a prática contém código que é lento e não performa quando sob alta demanda
  • O código/a prática contém código ilegível
  • O código/a prática contém código reduntante (que não tem nenhuma ação prática)

 

(CONTINUA)

  

ASP .NET MVC – Introdução

Antes de falarmos da tecnologia propriamente dita, é salutar entender como surgiu o conceito do MVC.

O termo MVC (Model – View – Controller) foi, originalmente, proposto por TrTrygve Reenskaugygve Reenskaug, que era desenvolvedor Smalltalk, enquanto participava de um projeto para desenvolver um computador portátil que conteria todos os dados de interesse para seu usuário ou dono (Dynabook). Além disso, esses dados também deveriam incluir os programas utilizados para manipulação deles e o usuário/dono deveria ter a possibilidade de entender e escrever programas, aumentando seu domínio sobre o sistema.  Reenskaug mantém um site, onde explica com suas próprias palavas o conceito MVC, que ele desenvolveu em 1978. No site também é possível encontrar um artigo através do qual Reenskaug apresenta sua teoria para a comunidade internacional.

Se você quiser acessar uma breve descrição do significado dos termos Model, View e Controller, por favor, acesse este post no meu blog ou então aguarde o desenvolvimento deste séria de posts sobre ASP.NET. Ao longo dos posts estes conceitos ficarão mais claros e você poderá associá-los facilmente com a parte tecnológica, que coloca isso tudo para funcionar! Alegre

O ASP.NET MVC, por sua vez, é um Framework de desenvolvimento Web que segue as linhas do padrão de arquitetura MVC, o que nos permite aproveitar ao máxico a eficácia do padrão [MVC] e as idéias mais recentes de desenvolvimento ágil, sem perter todo o poder da plataforma ASP.NET.

Para entender por quê o ASP.NET MVC têm ganhado tanta importância, vamos fazer uma breve análise da evolução do Desenvolvimento Web com a plataforma Microsoft:

 

1993

  • CGI – Common Gateway Interface
    • Era uma maneira flexível de gerar conteúdo dinâmico. No início era a única alternativa para gerar conteúdo mais elaborado ou interativo. Trata-se de uma forma de comunicação entre o servidor Web e um programa executável arbitrário que retorna um conteúdo dinâmico. Foi inicialmente proposto pela NCSA – National Center of Supercomputing Applications, mas não é mais mantido pela entidade.
      (Não era mantido pela Microsoft, mas merece destaque por ser o precursor da Web Dinâmica)

1996

  • ASP – Active Server Pages
    • Na época representou um avanço para o desenvolvimento web, permitindo a criação de conteúdos dinâmicos de propósito geral. Entretanto, era interpretada em tempo de execução (e com todos os problemas a que isso tem direito) e tornava resultava em um código emaranhado, que misturava a lógica da apresentação com sua apresentação (código HTML). Essa mistura e comumente conhecida como código espaguetti. Fica difícil seguir uma linha de raciocínio quando se têm um código tão emaranhado.

2002 – 2003

  • ASP.NET Web Forms 1.0/1.1
    • Representou uma mudança radical nos paradigmas de desenvolvimento Web. O código era compilado, a interface de usuário permitia a preservação do estado (o valor/estado dos objetos da interface se mantinha entre as várias requisições/post-postback nas páginas). Foi a primeira tentativa de oferecer um padrão com divisão em camadas e um “encapsulamento” do Desenvolvimento Web. Entretanto, a maneira como o funcionamento dos Web Forms foram projetados levava a um aumento no consumo de banda (tanto por parte dos servidores quanto por parte dos clientes), pois para que os controles pudessem manter a seu estado, uma quantidade extra de informação era gerada e enviada para o cliente e, depois, novamente enviada para o servidor, causando um overhead na comunicação entre os dois. Além disso, os projetos ASP.NET Web Forms são extremamente difíceis de testar e geravam (até a versão 4.0 do Web Forms) um resultado HTML extremamente complexo e difícil de integrar com JavaScript.

      Por encapsulamento do Desenvolvimento Web, refiro-me à preservação do estado, já que o funcionamento das resições Web são, por natureza, sem preservação de estado e pelo mecanismo utilizado pelo ASP.NET Web Forms para associar os eventos de interface à execução do código compilado no lado servidor. Muitas vezes, quando era necessário manipular os controles dinamicamente essa “amarração” entre o evento na interface do usuário (por exemplo o clique em um botão) e a execução do código correspondente àquela ação no lado servidor simplesmente não funcionava, além dos famosos erros de View State.

2005

  • ASP.NET Web Forms 2.0
    • Foram introduzidos vários controles/componentes que reduziam a quantidade de código que os desenvolvedores precisavam construir. Veja mais sobre as novidades do ASP.NET 2.0 neste artigo da MSDN Magazine.

2007

  • ASP.NET AJAX
    • Foi a resposta da Microsoft ao aumento da popularidade do AJAX, permitindo uma melhor interatividade no lado cliente das aplicações.

2008

  • ASP.NET Web Forms 3.5
    • Foram incluídos novos controles, como o ListView e o LinqDataSource. Veja mais sobre as novidades do ASP.NET 3.5 aqui.

2009

ASP.NET MVC 1.0

2010

  • ASP.NET MVC 2.0
  • ASP.NET Web Forms 4.0
    • Pela primeira vez o ASP.NET Web Forms começa a respeitar mais seriamente os padrões Web.

2011

  • ASP.NET MVC 3.0

2012

  • ASP.NET MVC 4.0
  • ASP.NET Web Forms 4.5

 

É importante entender que o ASP.NET Web Forms é um conjunto de componentes de interface dotados de um modelo de programação com preservação de estado e orientado à objetos. Esses compoentes são construídos e rodam sobre uma base, que é o ASP.NET.

image

 

O ASP.NET, por sua vez, roda sobre a base do .NET Framework, que fornece uma série de recursos e ferramentas para desenvolvimento, teste, deploy, execução e depuração de aplicações.

KnockoutJS e ASP.NET MVC

KnockoutJS é um Framework JavaScript que segue o padrão MVVM (Model-View-ViewModel).

Padrões são guidelines, orientações que auxiliam na resolução de problemas comumente encontrados no Desenvolvimeto e Projeto de Software. O padrão MVVM é usualmente considerado como uma evolução do padrão MVP (Movel-View-Presenter que, por sua vez, surgiu de uma evolução do padrão MVC) por não precisar de uma referência direta para a View (como acontece no MVP) e, assim como seus precursores, também propõe a separação de responsabilidades (a exemplo, lógica de negócio e dados da interface).

O padrão MVVM foi, originalmente, proposto por John Gossman em 2005 para o desenvolvimento de aplicações WPF e é muito parecido com o Presentation Model, proposto por Martin Fowler em 2004. Ambos (Presentation Model e o MVVM) propõem uma abstração da View. A principal diferença, entretanto, se da no fato de que Martin Fowler propôs o PM para fornecer uma abstração da View independente de plataforma, enquanto John Gossman introduziu o MVVM como uma padronização que aproveitava as características do WPF para construção de interfaces, sendo, praticamente, uma especialização do Presentation Model.

Com o passar do tempo, o padrão MVVM foi se difundindo e se desvinculou do WPF, como no caso do Knockout, que foi construído utilizando JavaScript.

Vejamos as responsabilidades de cada uma das partes do MVVM:

Model
É responsável pelos dados e a pela lógica de negócio da aplicação Por exemplo, Clientes, uma lista de contatos, regras matemáticas utilizadas para cálculo de uma projeção, etc.

View
A View é responsável pela aparência da aplicação e por fornecer controles com os quais os usuários interagem. Os dados podem ser exibidos pela view através de um mecanismo conhecido como DataBind, que permite fazer a vinculação entre propriedades (a propriedade Text de um Label a propriedade Nome de um objeto em memória, por exemplo).

ViewModel
Utiliza um ou mais Models para expor propriedades, que depois são bindadas às Views e também passa comandos para o Model.

image

A View tem conhecimento do ViewModel, mas não do Model. O ViewModel, por sua vez, tem conhecimento somente do Model. E o Model não tem conhecimento das outras duas partes.

Entre as vantagens em se utilizar o padrão MVVM podemos citar:

  • Melhora na integração entre Designers e Desenvolvedores
  • Facilita a troca da Interface de Usuário
  • Melhora a extensibilidade do projeto
  • Melhora a estruturação do sistema
  • Facilita a manutenção
  • Separação de responsabilidades
  • Melhora a testabilidade
  • Reduz o tempo de desenvolvimento
  • Facilita a customização das aplicações

Nos próximos posts vou postar exemplos de como utilizar o KnockoutJS nas Views do ASP.NET MVC, permitindo a implementação MVVM no browser.

Technorati Marcas: ,,,

Configurando o Beyond Compare no Visual Studio 2010 e Team Foundation Server

Se você está acostumado a trabalhar com o Visual Studio conectado ao Team Foundation Server já deve ter se deparado com uma situação de conflito de versões em que é necessário fazer uma combinação entre a versão do repositório e a versão com as alterações. Muito embora o Visual Studio e o TFS tenham uma ferramenta que possibilite fazer o merge, ela possui pouca flexibilidade.

Uma ferramenta (comercial) que gosto bastante é o Beyond Compare. Você também pode utilizar uma alternativa gratuita como o WinMerge, por exemplo.

Para configurar o Beyond Compare para ser utilizado com o Visual Studio e o Team Foundation Server bastam alguns passos simples:

  1. No menu Tools, escolha a opção Options.
    image
  2. Na árvore de opções à esquerda, expanda Source Control e selecione o item Visual Studio Team Foundation Server.
    image
  3. Clique no botão Configure User Tools…
  4. Na janela que se abrir, precisaremos inserir duas configurações: uma para Comparação e uma para Combinação (Merge).
    image
  5. Clique no botão Add…
  6. Preencha o formulário de acordo com a Tabela abaixo
    image
  7. Item

    Compare

    Merge

    Extension

    .*

    .*

    Operation

    Compare

    Merge

    Command

    <caminho para o BeyondCompare.exe>

    <caminho para o BeyondCompare.exe>

    Arguments

    %1 %2 /title1=%6 /title2=%7

    %1 %2 /savetarget=%4 /title1=%6 /title2=%7

Agora você já pode utilizar os recursos de Compare e Merge do Visual Studio e os fontes serão abertos no Beyond Compare.