terça-feira, 4 de novembro de 2008

Fazer tijolos ou juntar tijolos, eis a questão ...

Apôs tanto tempo a dizer que iria começar a escrever no blog, aqui vai a meu 1º input.Antes de mais nada atenção que isto pode ir com algumas gralhas.Porque além de ser burro e preguiçoso, não vou andar a fazer revisão.

Bem o meu titulo é estranho! Mas se o analisarem com alguma abstracção, se calhar conseguem ver aquilo que eu escondi nele.
Actualmente os programadores debatem-se com o constante trabalho de "fazer tijolos" e perdem pouco tempo a procurar os que já estão feitos. Uma das razões é porque para alguns nunca existe o "tijolo" exactamente como eles querem, outros preguiça de procurar, outros não têm tempo, outros não gostam, etc. Existe sempre uma razão.

No meu trabalho do dia a dia, verifico que cerca de 75% do nosso tempo consiste em refazer o que já esta feito, muitas vezes mal.Mais tarde verificamos que já alguém o fez e bem melhor. Existem alguns que ao fim de algum tempo tem os seus "private tijolos". Então já passam para a fase de os "juntar". Mas muito poucos na realidade utilizam conscientemente "tijolos" de outros para atingir o seu objectivo.

Chega de falar em tijolos e vamos falar do problema em si. Ao fim de algum tempo muitos dos problemas na programação já foram resolvidos por alguém. As vezes essas soluções estão padronizadas e disponíveis para nós utilizarmos. O problema é saber que existem e como utilizar.

Para já vou falar de um conjunto de soluções que a Microsoft disponibiliza para uma série de situações, o Enterprise library.

O Enterprise library não é mais do que um conjunto de unidades "application blocks" configuraveis que podem ser utilizados para resolver uma série de problemas comuns.



Como podem verificar na imagem existem uma série de problemas comuns as aplicações.
Em cada nova aplicação lá vamos nós resolver aquilo que "n" vezes já resolvemos.
Ora com esta solução a Microsoft tenta dar mecanismos que possam ser adaptados as nossas aplicações e que permitam uma forma padrão de resolver os problemas mais comuns.

Inicialmente em janeiro de 2005 a microsoft disponibilizou os seguintes "Apllication Blocks", na versão 1.0.
• Configuration Application Block
• Data Access Application Block
• Caching Application Block
• Exception Handling Application Block
• Logging and Instrumentation Application Block
• Security Application Block
• Cryptography Application Block

Com a versão 2.0, actualizou para a framework 2.0 e alterou os modulos de
• Data Access Application Block
• Caching Application Block
• Exception Handling Application Block
• Security Application Block

E

. O Logging and Instrumentation Application Block , passou so a ser o Logging
Application Block

. O funcionalidade de Instrumentation que existia no "Logging and Instrumentation Application Block" como o Configuration Application Block passaram a ser tranversais as "Application Blocks".

Com a versão 3.0 passou a coexistir com novas funcionalidades da framework dot net.
• Windows Presentation Framework
• Windows Communication Framework
• Windows Workflow Foundation
• Windows CardSpace

Novos "Apllication Blocks" apareceram.
• Validation Application Block
• Policy Injection Application Block

E outros estão disponiveis mas não são oferecidos no core.

• Composite UI Application Block:
• Updater Application Block:
• CompositeWeb Application Block
• Page Flow Application Block
• Mobile Composite Application Block
• Mobile Data Access Block
• Mobile Configuration Block
• Mobile Connection Monitor Block
• Mobile Data Subscription Block
• Mobile Disconnected Service Agent Block
• Mobile Endpoint Catalog Block
• Password Authentication Block

E ainda existe a versão 4.0, que aborda a framework 3,0/3.5, que falarei mais a frente.

No fundo interessa saber é que existem muitas coisa já feitas que podem ser aproveitadas.E o meu objectivo será nestes "posts", falar das principais e se possível de todas.

Agora para terminar, porque ja escrevi muito, deixo só a nota que o próximo post irá falar de como instalar e usar em desenvolvimento e produção estes "Applications Blocks". Se possível falar em detalhe de um, talvez o de "LOG", senão fica no "post" seguinte.

Sabem a vontade é muita o tempo é que não abunda.

Um abraço, comentem ...

4 comentários:

Inês Ferreira disse...

Pois, muitos programadores que eu conheço de facto passam a vida a reinventar a "roda". Este é um blog importante na medida em que pode mostar que de facto não estamos sós na resolução de problemas e basta procurar um pouco para que se encontre uma solução. Apesar do blog ser muito microsoft, a ideia é inerente a tudo aquilo que se possa trabalhar. Não se esqueçam que um bom programador não é aquele que faz muito, é aquele que faz bem.

Duarte Cunha Leão disse...

Olá Joaquim! Gostei de ler. Fizeste um bom apanhado dos (muitos) blocos da (biblioteca) Enterprise Library.
Reparei que não referiste um bloco que considero (muito) importante, o Unity.
Fico à espera do teu próximo artigo!

Duarte Cunha Leão disse...

Já agora, quanto à "provocação" do título do artigo...Gosto de juntar tijolos, quando são bons tijolos, e fazê-los de novo, caso contrário.
Acho que muitos dos bons tijolos existentes não se integram bem uns com os outros; ou, se juntos, tornam um projecto numa panóplia de bibliotecas com diferentes configurações, estilos e abordagens — não existe aproveitamento de módulos comuns de suporte.
Um dos (muitos) aspectos positivos da Enterprise Library é que foi desenhada de forma integrada, modular, com partes comuns.
Depois, tem o selo e o estilo Microsoft — algo que é facilmente distinguível, caso se compare esta com o Spring.Net, por exemplo, que inevitavelmente herda a "forma Java de fazer as coisas", algo que aos programadores .Net, causa alguma estranheza. É de realçar, também, o factor garantia Microsoft, algo que é especialmente valorizado pelo primeiro herdeiro do código: o cliente.
Valorizada devidamente a Enterprise Library, posso agora, humildemente, justificar a vontade de fazer melhor, com outra questão:
Porque fez a Microsoft a Enterprise Library, quando existiam outras bibliotecas maduras, gratuitas, coerentes...?

Duarte Cunha Leão disse...

@necaines: Só agora apareceu o teu comentário de 5 de Novembro :-) ...

Na minha opinião, um bom programador não é nem "aquele que faz muito" nem "aquele que faz bem"... e mudaria a frase para algo mais relativo como "um melhor programador é aquele que faz o melhor possível com o menos possível"...

O problema está em definir o que é ser "bom", ou fazer "bem". Nuns casos, ser bom, pode ser fazer muito (mas o menos possível, claro) e noutros fazer pouco (o menos possível, também). Discordo apenas do uso de termos absolutos e subjectivos :-).

Quanto a passar a vida a reinventar a roda, para mim, esse é um dos traços patentes em pessoas com espírito crítico, conhecedoras, informadas, inconformadas, criativas, etc (a menos que estejamos a falar de casos de autismo).
Por outro lado, as pessoas que constantemente criticam quem constantemente reinventa são, por vezes, donas de um espírito mandrião, estéril, marteleiro, etc, e enaltecem-se fazendo chacota de quem faz qualquer coisa, melhor feita.

É verdade que a solução está muitas vezes à distância de umas keywords bem escolhidas, e é certamente frustrante quando, depois de fazermos algo, de novo, vimos a descobrir igual, já feito e classificado no único sinónimo que não experimentámos!

Outras vezes o entusiasmo de fazer algo diferente leva a melhor e quase que fechamos os olhos para não ver a solução já-feita que aparece em primeiro lugar no Google :-)

Só queria deixar claro que há outras maneiras de ver as coisas.