Nous sommes actuellement dans une situation où nous avons le choix entre utiliser un mappeur relationnel objet prêt à l'emploi ou rouler le notre
Nous avons une application héritée (ASP.NET + SQL Server) où la couche de données et la couche métier sont malheureusement écrasées ensemble. Le système n'est pas particulièrement compliqué en termes d'accès aux données. Il lit les données d'un grand groupe (35-40) de tables interdépendantes, les manipule en mémoire et les enregistre dans d'autres tables dans un format récapitulatif. Nous avons maintenant la possibilité de refactoriser et étudions les technologies candidates à utiliser pour séparer et structurer correctement notre accès aux données.
Quelle que soit la technologie que nous décidons, nous aimerions:
- avoir des objets POCO dans notre modèle de domaine qui sont ignorants de la persistance
- avoir une couche d'abstraction pour nous permettre de tester nos objets de modèle de domaine contre une source de données sous-jacente simulée
Il y a évidemment beaucoup de choses là-dessus déjà en termes de modèles et de cadres, etc.
Personnellement, je fais pression pour utiliser EF en conjonction avec le générateur de référentiel testable d'unité ADO.NET / le générateur d'entité POCO . Il répond à toutes nos exigences, peut être facilement intégré dans un modèle Repo / UnitOfWork et notre structure de base de données est raisonnablement mature (ayant déjà subi une refactorisation) de sorte que nous n'apporterons pas de modifications quotidiennes au modèle.
Cependant, d'autres membres du groupe suggèrent d'architecturer / rouler complètement notre propre DAL à partir de zéro. (DataMappers personnalisés, DataContexts, référentiel, interfaces partout, dépendance excessive à l'injection de dépendance pour créer des objets concrets, traduction de requête LINQ vers sous-jacente personnalisée, implémentations de mise en cache personnalisées, implémentations FetchPlan personnalisées ...) la liste continue et pour être honnête, il y a des grèves moi comme une folie.
Certains des arguments avancés sont "Eh bien, au moins, nous contrôlerons notre propre code" ou "Oh, j'ai utilisé L2S / EF dans un projet précédent et ce n'était que des maux de tête". (Bien que j'aie déjà utilisé les deux en production auparavant et que je trouve que les problèmes sont rares et très gérables)
Alors, l'un de vos développeurs / architectes très expérimentés a-t-il des paroles de sagesse qui pourraient m'aider à éloigner ce produit de ce qui me semble être un désastre complet. Je ne peux pas m'empêcher de penser que tout avantage obtenu en esquivant les problèmes EF, sera perdu tout aussi rapidement en tentant de réinventer la roue.