LINQ x DAO, FACTORY

Question

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."

 

Answer 1

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.

 

 

 

Answer 2

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

Answer 3

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!