none
LINQ x DAO, FACTORY RRS feed

  • Discussão Geral

  • Boa noite senhores, ontem comecei um projeto e resolvi utilizar o novo framework para me beneficiar dos novos recursos disponíveis.O principal dele, no meu ponto de vista, é o LINQ.Como sempre, faço um estudo sobre a solução e tenho sempre a prática de dividir em camadas, pensar em aspectos de performance segurança e outros, resumindo, definir a arquitetura da solução.

     

    Tenho como prática desenvolver uma camada de dados e outra camada de negócios (além de outras de controller, communications e etc mas nesse momento não vem ao caso).Na camada de dados, geralmente, tento colocar instruções selects mais genéricas e fazer toda a lógica dentro da camada de negócio.Abaixo vou descrever um exemplo do que estou falando.

     

    ###############################################################################

     

    Class: ClientBO

    Methods

    clientDao GetClientsNoPay(Client client);

    {

    IClientDAO clientDao = FactoryDAO.InstanceDAO<IClientDAO>;

    return clientDao.GetClients(Client client);

    ///regra de negocio etc....

    }

     

    Class: ClientDAO: IClientDAO

    Methods

    IClientDAO.GetClients(Client client);

     

    Static Class:FactoryDAO<T>

    Properties

    InstanceDAO<T>

    {

    return (T)Assembly.CreateInstance(config,typeDb);

    }

    ###############################################################################

     

    Não vou mais me extender com códigos e etc.a questão é que com o LINQ, teoricamente, podemos eliminar a classe DAO e fazer o "select" dentro da business, certo ?

     

    ###############################################################################

     

    Class: ClientBO

    Methods

    clientDao GetClientsNoPay(Client client);

    {

    var Clients = FROM _client IN dbContext.tbClients

                       WHERE _client.pedidos.pagamento !=0

                       SELECT _client;

    }

    ###############################################################################

     

    Mas e se o cliente mudar de ideia em relação ao banco de dados (isso quase nunca acontece né, contratos mais baratos, oracle fazendo propostas e etc), teríamos que fazer refactoy ? poderiamos manter o modelo do exemplo um e criar as LINQqueries em um ClientDAO, mas não seria uma perda de perfomance considerável ? ter uma camada que, teoricamente, não faz mais nada ?

     

    Gostaria de comentários, queria muita discutir, queria muita estar em um empresa com mais pessoas que gostassem de arquitetura... mas é a vida.

     

    Agradeço o tempo que todos vocês possam perder lendo essas linhas e me desculpem por possíveis erros de sintáxe

     

    Um grande abraço,

    Paulo Silva !!!

    Velho provérbio chinês que li no blog do arquiteto Otávio Pecego...

    "

    "Eu ouço e eu esqueço. Eu vejo e eu me lembro. Eu faço e eu entendo."

     

    segunda-feira, 4 de agosto de 2008 00:54

Todas as Respostas

  • Paulo não olhei a implementação em si, apenas o contexto do problema.

    Se estiver utilizando Linq to SQL e querer mudar de banco de dados vai ter impacto sim, e muito.

    Uma solução para isso é Linq to Entities.

    Ou você cria Factory DAO (ou DbProviderFactory que já existe no framework 2.0 e implementa este conceito, sendo possivel herdar e aprimorar, caso necessário) e utilizar LINQ em lista/objeto de classes mapeadas (VO, DTO, MapperObject, etc).

     

    Uma dica, utilize Lambda. Pois se não estou enganado, a sintaxe do LINQ é passada para Lambda...vc economiza nisso, acredito que não se ganha muito em termo de performance.

     

     

     

    sábado, 16 de agosto de 2008 18:31
  • Opa,

    Também já notei que a camada de Dados pode ser removida da aplicação mas já vi matérias sobre a implementação da camada de dados utilizando o LINQ.

    Da uma olhada em:

    http://code.msdn.microsoft.com/multitierlinqtosql
    quarta-feira, 3 de setembro de 2008 17:18
  • Cara,

    Estou fazendo um trampo e resolvi me aventurar no LINQ to SQL também. Para modelar minha aplicação usei + - os esquemas do Domain Model, no caso utilizei Entity, Repository e Service basicamente.

    Para usar o esquema de arrastar e soltar do LINQ to SQL, criei uma pseudo-DAO rsrsrsrs que nada mais são do que as tabelas que transformei em classes do LINQ to SQL.

    Então tenho minas entidades de negócio e as classes do LINQ. Na minha Repository eu instancio o Context apropriado e faço as consultas e persistencias conforme for necessário, utilizando o LINQ mesmo. A "gambers" foi uma classe chupa-cabras que eu fiz, para converter a entidade do LINQ to SQL para os dados da minha entidade de negócio, pra isso não consegui achar outra solução.

    Achei que ficou bem simples e de fácil manutenção. Sei lá, ainda não acabei o trampo, vamos ver o que vai dar até o final.

    Abraço!
    terça-feira, 30 de setembro de 2008 19:57