Do jeito que era
Durante anos, organizei minhas soluções de software da seguinte forma:
- Data Access Layer (DAL) para abstrair o negócio de acessar dados
- Business Logic Layer (BLL) para aplicar regras de negócios a conjuntos de dados, manipular autenticação etc.
- Utilitários (Util), que é apenas uma biblioteca de métodos utilitários comuns que construí ao longo do tempo.
- Camada de apresentação, que pode ser, obviamente, web, desktop, móvel, qualquer que seja.
Do jeito que está agora
Nos últimos quatro anos, eu tenho usado o Entity Framework da Microsoft (sou predominantemente um desenvolvedor .NET) e estou descobrindo que ter o DAL está se tornando mais complicado do que limpo, devido ao fato de que o Entity Framework já fez o trabalho que meu DAL costumava fazer: abstrai o negócio de executar CRUDs em um banco de dados.
Portanto, normalmente acabo com um DAL que possui uma coleção de métodos como este:
public static IQueryable<SomeObject> GetObjects(){
var db = new myDatabaseContext();
return db.SomeObjectTable;
}
Em seguida, no BLL, esse método é usado como tal:
public static List<SomeObject> GetMyObjects(int myId){
return DAL.GetObjects.Where(ob => op.accountId == myId).ToList();
}
Este é um exemplo simples, é claro, pois o BLL normalmente teria várias outras linhas de lógica aplicadas, mas parece um pouco excessivo manter um DAL para um escopo tão limitado.
Não seria melhor simplesmente abandonar o DAL e simplesmente escrever meus métodos BLL como tal:
public static List<SomeObject> GetMyObjects(int myId){
var db = new myDatabaseContext();
return db.SomeObjectTable.Where(ob => op.accountId == myId).ToList();
}
Estou pensando em retirar o DAL de projetos futuros pelas razões expostas acima, mas, antes de fazê-lo, queria pesquisar a comunidade aqui por suas retrospectivas / previsões / opiniões antes de seguir adiante em um projeto e descobrir um problema que não resolvi ' t antecipar.
Quaisquer pensamentos são apreciados.
Atualizar
O consenso parece ser que um DAL separado não é necessário, mas (fazendo minha própria inferência aqui) é uma boa idéia para evitar o bloqueio do fornecedor. Por exemplo, se eu tiver um DAL que abstraia as chamadas EF, como ilustrado acima, se eu sempre mude para outro fornecedor, não preciso reescrever minha BLL. Somente essas consultas básicas no DAL precisariam ser reescritas. Dito isto, acho difícil imaginar um cenário em que isso aconteceria. Eu já posso fazer um modelo EF de um banco de dados Oracle, o MSSQL é um dado, tenho certeza de que o MySQL também é possível (??), portanto, não tenho certeza se o código extra concederia um ROI valioso.
GetMyObjects(int myId)é mais fácil do que zombar / arrancar / fingirGetObjects.Where(ob => op.accountId == myId).ToList().Respostas:
Não tenho certeza se esta é a resposta que você está procurando ... mas aqui vai.
Fazemos isso para manter as coisas separadas / organizadas. Sim, EF / NHibernate são acesso a dados .. mas limitamos seu uso ao seu próprio assembly com uma configuração genérica de repositório. Esse assembly também contém todos os nossos mapeamentos do NHibernate, Session Factory, código para manipular vários bancos de dados, etc.
Ainda o chamamos de "Camada de acesso a dados", porque o conjunto inteiro existe para oferecer suporte ao nosso ORM.
Provavelmente, devo observar que nosso aplicativo principal faz referência a 5 bancos de dados, possui aproximadamente 4-500 objetos / mapeamentos de domínio e vários esquemas. Portanto, essa configuração faz sentido para nós. Talvez para um aplicativo menor você pule esse assembly, mas .. Eu sou um otário por código organizado e provavelmente faria isso de qualquer maneira :)
fonte
Eu vejo o EF e o DAL como componentes separados em um sistema Enterprise. A camada de acesso a dados é uma abstração usada por outros serviços para executar a persistência e o gerenciamento de dados. Normalmente, os Entity Frameworks criam uma API agradável em torno da consulta, atualização, exclusão e inserção, no entanto, no núcleo, eles ainda exigem uma conexão direta com a fonte de dados de back-end. Portanto, qualquer tipo de roteamento ou firewall interrompe o funcionamento do EF, exigindo que você crie um componente de mediação EF.
Aqui está um exemplo de alto nível que mostra onde DAL e EF se encaixam:
Foi minha experiência que um design melhor é nunca permitir que a lógica de negócios ou as implementações de serviço tenham acesso direto à camada EF. Em vez disso, forneça uma abstração para trabalhar com todos os dados persistentes, o que permite enviar solicitações por cabo ou executá-las localmente.
Esse design apresenta algumas abstrações com vazamentos. Portanto, deve ser considerado caso a caso.
Algumas perguntas a serem feitas:
fonte
Atualmente, a questão de alterar ou não o armazenamento de dados é mais interessante do que costumava ser, já que a questão pode não ser apenas se você trocaria ou não o MS SQL ou o Oracle SQL, mas a questão maior sobre se você pode usar em várias ofertas de armazenamento de dados NoSQL como seu repositório de dados.
Se houvesse uma possibilidade séria desse tipo de alteração, pode ser valioso manter seu código EF isolado dentro do seu DAL, para que você possa introduzir um novo DAL no futuro que mapeie suas solicitações de repositório para um banco de dados NoSQL. Pode ser que essa mudança acabe com uma reescrita por atacado da sua BLL de qualquer maneira, devido a suposições relacionadas ao banco de dados que se arrastam, é claro.
Da mesma forma, a EF dentro de um DAL provavelmente tornaria a simulação do acesso a dados para seus testes de unidade de código BLL mais simples.
Portanto, minha opinião é que a EF (ou outro ORMS) não anula necessariamente a necessidade de uma camada de acesso a dados.
fonte