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 / fingir GetObjects.Where(ob => op.accountId == myId).ToList().