De la forma que era
Durante años, he organizado mis soluciones de software como tales:
- Capa de acceso a datos (DAL) para abstraer el negocio de acceder a datos
- Business Logic Layer (BLL) para aplicar reglas comerciales a conjuntos de datos, manejar autenticación, etc.
- Utilidades (Util), que es solo una biblioteca de métodos de utilidad comunes que he construido con el tiempo.
- Capa de presentación que, por supuesto, podría ser web, escritorio, móvil, lo que sea.
Como es ahora
Durante los últimos cuatro años más o menos, he estado usando Entity Framework de Microsoft (soy predominantemente un desarrollador de .NET) y descubrí que tener el DAL se está volviendo más engorroso que limpio debido al hecho de que Entity Framework ya ha hecho el trabajo que solía hacer mi DAL: abstrae el negocio de ejecutar CRUD en una base de datos.
Entonces, generalmente termino con un DAL que tiene una colección de métodos como este:
public static IQueryable<SomeObject> GetObjects(){
var db = new myDatabaseContext();
return db.SomeObjectTable;
}
Luego, en el BLL, este método se usa como tal:
public static List<SomeObject> GetMyObjects(int myId){
return DAL.GetObjects.Where(ob => op.accountId == myId).ToList();
}
Este es un ejemplo simple, por supuesto, ya que el BLL normalmente tendría varias líneas lógicas más aplicadas, pero parece un poco excesivo mantener un DAL para un alcance tan limitado.
¿No sería mejor simplemente abandonar el DAL y simplemente escribir mis métodos BLL como tales:
public static List<SomeObject> GetMyObjects(int myId){
var db = new myDatabaseContext();
return db.SomeObjectTable.Where(ob => op.accountId == myId).ToList();
}
Estoy considerando dejar el DAL de futuros proyectos por las razones indicadas anteriormente, pero antes de hacerlo, quería encuestar a la comunidad aquí por su retrospectiva / previsión / opiniones antes de comenzar un proyecto y descubrir un problema que no conocí. No anticipo.
Cualquier pensamiento es apreciado.
Actualizar
El consenso parece ser que no es necesario un DAL por separado, pero (haciendo mi propia inferencia aquí) es una buena idea evitar el bloqueo del proveedor. Por ejemplo, si tengo un DAL que está abstrayendo las llamadas EF como se ilustra arriba, si alguna vez cambie a otro proveedor. No necesito reescribir mi BLL. Solo esas consultas básicas en el DAL tendrían que reescribirse. Dicho esto, me resulta difícil imaginar un escenario en el que esto suceda. Ya puedo hacer un modelo EF de una base de datos Oracle, MSSQL es un hecho, estoy bastante seguro de que MySql también es posible (??), así que no estoy seguro de si el código adicional otorgaría un ROI que valga la pena.
GetMyObjects(int myId)es más fácil que burlarse / tropezarse / falsificarse GetObjects.Where(ob => op.accountId == myId).ToList().