Intéressant - Je mettrais l'abstraction entre le BL et le DAL avant que je Pour ce faire, pour la couche de présentation
L'approche utilisée dans votre autre question semble raisonnable - Pourquoi ne réutilises-tu pas ça?
- Oui, vous avez besoin d'une usine; mais vous pouvez l'inclure dans une classe/un assemblage commun et lui renvoyer simplement un
object, que vous pouvez ensuite lancer au retour - i.e: au point dans le BL où il est appelé.
- (pour l'exhaustivité :) en utilisant
Activator.CreateInstance() (comme vous l'avez utilisé dans votre autre question) est la bonne façon de procéder.
- Pour DAL j'ai tendance à utiliser les valeurs stockées dans la configuration (comme arguments pour passer en usine); il n'est pas courant de changer souvent l'implémentation de la couche DAL - donc la configuration fonctionne bien pour moi.
- Observez le Interface Segregation Principle (ISP) lors de la conception de la contractr/abstraction entre le BL et DAL - si vous le faites correctement, vous serez en mesure de mélanger et mettre en œuvre différentes implémentations physiques DAL à la fois.
- Si vous conservez les DTO et l'usine dans un assemblage commun (éventuellement le même), il est facile de les réutiliser avec le BL et diverses implémentations DAL - avec l'avertissement que vous conservez cette classe commune comme étant dépourvue de dépendances comme possble. Si vous faites cela, vous serez en mesure d'ajouter/udpater les implémentations DAL sans recompiler et redéployer l'ensemble du système.
Je ne vois pas pourquoi quelqu'un est en train de voter pour fermer ceci, cela semble être une bonne question. Il demande des meilleures pratiques et des approches pour l'abstraction de son accès aux données. Cela ressemble au genre de chose que nous voulons favoriser. Peut-être reformuler la question un peu? – David
@David: sa question précédente est très détaillée, avec un peu de contexte. Cette continuation manque de ça. Le PO obtiendrait de bien meilleures réponses, IMO, s'il édite sa question précédente avec ceci. –