Design Patterns - Parte 4 - Repository

by Cássio R Eskelsen 11. dezembro 2008 01:12

"Subindo" um pouco o nível da série de posts sobre design patterns, falarei hoje sobre o pattern "Repository".

Este pattern não é tão amplamente difundido, apesar de sua grande flexibilidade e poder de resolver nosso velho dilema de como isolar a persistência das demais camadas permitindo uma arquitetura plugável onde podemos utilizar múltiplos bancos de dados (na verdade, uma implementação concreta de repositório pode persistir dados em qualquer lugar, não necessariamente direto em um banco de dados.

Um repositório media o relacionamento entre o dominio e os dados. Imagine um repositório literalmente: é um lugar onde são guardadas coisas e coleções de coisas e onde efetuamos pesquisas dessas coisas.


Fonte: http://www.martinfowler.com/eaaCatalog/repository.html

Leia mais...

Ninguém avaliou. Dê sua nota!

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , ,

Design Pattern | Arquitetura

Linq to Sql Context único por aplicação

by Cássio R Eskelsen 14. setembro 2008 05:04

Otávio P. Coelho escreveu recentemente um post sugerindo o uso de singletons para manter o contexto de um Entity Data Model.

Venho utilizando essa estratégia há um bom tempo já  para minhas aplicações que usam Linq to SQL e a partir do post do Otávio resolvi compartilhar um trecho de código que pode ser usado por todos.

Qual a vantagem de criar um singleton para isso? Bom, imagine que uma determinada rotina do seu código precise “atravessar”  por vários métodos de instâncias de várias classes e imagine que essa “travessia” precise estar coberta por uma transação. Você não pode então criar uma instância do seu data context em cada método e passar um context já criado e passar como parâmetro é uma solução muito “feia” além  de não permitir a separação das suas regras de negócio da camada de persistência.

Com um singleton, os métodos passam a “buscar” um data context já aberto, ou, se ainda não estiver criado, instancia um novo.

Usando os métodos CallContext e SetContext podemos manter o data context no contexto da aplicação, o que significa que em aplicações Windows Forms ele estará válido durante toda a execução do programa, ou no caso de aplicações WEB, durante o ciclo de vida de uma chamada Http Request.

Essa solução é transparente para aplicações WEB e Desktop, ou seja, se sua camada de negócios e/ou sua camada de persistência são usadas simultaneamente nas duas plataformas, a solução não precisa ser “ajustada”.

Exemplo abaixo, DataRepository é o nome do meu Data Context. Substitua pelo seu.

using System.Runtime.Remoting.Messaging;

namespace LINQToSQL
{
    public class Helper
    {
        #region Privates

        private static string _stringConexao = null;

        private const string DATACONTEXT_ITEMS_KEY = "DBHelperContextKey";

        private static DataRepository DataBaseContext
        {
            get
            {
                return (DataRepository)CallContext.GetData(DATACONTEXT_ITEMS_KEY);
            }
            set
            {
                CallContext.SetData(DATACONTEXT_ITEMS_KEY, value);
            }
        }

        #endregion

        #region Public and Protected Properties and Methods

        /* a string de conexão você pode manter de várias formas
         * talvez a mais prática seja recuperar diretamente via ConfigurationManager
         */
        public static string StringConexao
        {
            get
            {
                return _stringConexao;
            }
            set
            {
                if (_stringConexao != null && _stringConexao.Equals(value))
                    return;

                //Se já tem um DatabaseContext criado, elimina ele para
                //que na próxima chamada seja reaberto com a nova string
                //de conexao.
                if (DataBaseContext != null)
                {
                    CleanUp();
                }

                _stringConexao = value;
            }
        }

        public static DataRepository Db
        {
            get
            {
                if (DataBaseContext == null)
                {
                    DataBaseContext = new DataRepository(StringConexao);
                }

                return DataBaseContext;
            }
        }

        public static System.IO.TextWriter Log
        {
            get
            {
                return Db.Log;
            }
            set
            {
                Db.Log = value;
            }
        }

        public static void CleanUp()
        {
            if (DataBaseContext != null)
            {
                DataBaseContext.Dispose();
                DataBaseContext = null;
            }
        }

        #endregion
    }
}

4.3 ponto(s). Avaliado por 3 pessoas

  • Currently 4,333333/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , ,

.Net | Arquitetura

Herança x interface x associação - quando usar um ou outro

by Cássio R Eskelsen 5. agosto 2008 13:45

Na empresa onde trabalho, estamos criando uma nova arquitetura de sistemas foi me solicitado que criasse um pequeno exemplo usando essa arquitetura, com as classes Cidade, Estado, etc.

A princípio, o design mais comum seria o de criar uma superclasse comum (ex. "Região") e a partir dela herdar cada uma.

No entanto, IMHO, não é uma resposa tão óbvia, já que uma Cidade "é um" Região mas também "é um" divisão política.

Talvez, nesse caso, fosse mais interessante usar Interface.

Alguns links para estudo:

http://guj.com.br/posts/list/87814.java

http://blog.caelum.com.br/2006/10/14/como-nao-aprender-orientacao-a-objetos-heranca/

http://www.datasuldirect.com.br/flash/JAVA_SC/Or_Obj.pdf

UPDATE (11/08)

Mais um post interessante sobre o mesmo assunto:No, inheritance is not the way to achieve code reuse!

UML or Not UML

by Cássio R Eskelsen 5. agosto 2008 13:44

 

Semana passada passei para alguns  o link http://blog.fragmental.com.br/2008/07/25/uh-eme-ele/ onde o Schoes (um programador bastante conhecido na comunidade JAVA brasileira) fala sobre alguns problemas com a UML.

Por coincidência em outro blog, este internacional, um cara postou um artigo chamado 13 Reasons For UML Descent Into Darkness.

Somado a outros artigos que já li, percebo que a UML não é mais considerada no meio como sendo a Panacéia que resolverá todos nossos problemas.

Alguns fatos que pinço dos textos:

----

"Acontece que ao passar do diagrama (e diagramas aceitam qualquer besteira) para o código (onde o compilador e testes unitários são muito exigentes – fora os usuários) o tal do pseudo-modelo criado pelo “analista” no Rational Rose (porque a empresa não percebeu que o Rose foi descontinuado há anos) é completamente diferente do modelo implementado. As classes até têm o mesmo nome mas a mecânica interna é bem diferente. E por quê? Porque UML não vai te oferecer tudo o necessário para modelar. O mínimo que se espera de um modelo de um sistema é que ele seja verificável para saber se cumpre seus requisitos. Como é que eu vou saber isso com UML? Como eu testo UML?"

"

---------

10. Lack of solutions for real software design issues

While the specifications are huge there are no good solutions for problems common in software systems. Quick examples are:

  • No solution for multi-tasking and communication between tasks
  • No dependency between use cases"

--------

5. Concept bloat

Trying to bridge UML to reality made it incorporate concepts from all the languages in fashion during the last 10-15 years. Anybody knows how to represent a Java anonymous inner class?

-------- 

Claro que não estou propondo abolirmos a UML. Apenas trouxe esse tema para reflexão pois acredito que não podemos levar a ferro e fogo a idéia de que nossos diagramas UML tenham que representar todos os nossos projetos e que existem ferramentas auxiliares muito importantes para o entendimento/manutenção de uma necessidade (como por exemplo, descritivos textuais, testes unitários, documentação de código fonte, etc).

Ninguém avaliou. Dê sua nota!

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: ,

.Net | Arquitetura | Projetos | UML