La façon dont c'était
Depuis des années, j'organise mes solutions logicielles en tant que telles:
- Couche d'accès aux données (DAL) pour résumer l'activité d'accès aux données
- Business Logic Layer (BLL) pour appliquer des règles métier aux ensembles de données, gérer l'authentification, etc.
- Utilitaires (Util) qui n'est qu'une bibliothèque de méthodes utilitaires communes que j'ai construites au fil du temps.
- Couche de présentation qui pourrait bien sûr être Web, bureau, mobile, peu importe.
La façon dont c'est maintenant
Depuis environ quatre ans, j'utilise Entity Framework de Microsoft (je suis principalement un développeur .NET) et je trouve que le fait d'avoir le DAL devient plus lourd que propre en raison du fait que Entity Framework a déjà fait le travail que mon DAL faisait: il fait abstraction de l’exécution de CRUD sur une base de données.
Donc, je me retrouve généralement avec un DAL qui a une collection de méthodes comme celle-ci:
public static IQueryable<SomeObject> GetObjects(){
var db = new myDatabaseContext();
return db.SomeObjectTable;
}
Ensuite, dans le BLL, cette méthode est utilisée comme telle:
public static List<SomeObject> GetMyObjects(int myId){
return DAL.GetObjects.Where(ob => op.accountId == myId).ToList();
}
C'est un exemple simple, bien sûr, car le BLL aurait généralement plusieurs lignes de logique supplémentaires appliquées, mais il semble juste un peu excessif de maintenir un DAL pour une portée aussi limitée.
Ne serait-il pas préférable d'abandonner simplement le DAL et d'écrire simplement mes méthodes BLL comme telles:
public static List<SomeObject> GetMyObjects(int myId){
var db = new myDatabaseContext();
return db.SomeObjectTable.Where(ob => op.accountId == myId).ToList();
}
J'envisage de supprimer le DAL de futurs projets pour les raisons indiquées ci-dessus mais, avant de le faire, je voulais interroger la communauté ici pour votre recul / prévoyance / opinions avant de me lancer sur un projet et de découvrir un problème que je n'ai pas rencontré '' t anticiper.
Toutes les pensées sont appréciées.
Mise à jour
Le consensus semble être qu'un DAL distinct n'est pas nécessaire mais (faire ma propre inférence ici) est une bonne idée pour éviter le verrouillage du fournisseur. Par exemple, si j'ai un DAL qui résume les appels EF comme illustré ci-dessus, si je jamais passer à un autre fournisseur, je n'ai pas besoin de réécrire mon BLL. Seules les requêtes de base dans le DAL devraient être réécrites. Cela dit, j'ai du mal à envisager un scénario dans lequel cela se produirait. Je peux déjà faire un modèle EF d'une base de données Oracle, MSSQL est une donnée, je suis presque sûr que MySql est également possible (??), donc je ne sais pas si le code supplémentaire accordera jamais un retour sur investissement intéressant.
GetMyObjects(int myId)
est plus facile que se moquer / écraser / truquer GetObjects.Where(ob => op.accountId == myId).ToList()
.