Lors de la conception d'objets métier, j'ai essayé plusieurs méthodes d'écriture de la couche d'accès aux données. Certains ont mieux travaillé que d'autres, mais j'ai toujours pensé qu'il devait y avoir un «meilleur» moyen. Je voudrais vraiment juste voir les différentes façons dont les gens ont géré le DAL dans différentes situations et leur opinion sur la façon dont la technique a fonctionné ou n'a pas bien fonctionné.Conception d'objet métier DAL
Malheureusement, je ne pense pas qu'il existe un "meilleur moyen", cela dépend trop de la situation spécifique de l'approche DAL que vous utilisez. Une grande discussion de «l'état de l'art» est Patterns of Enterprise Application Architecture par Martin Fowler.
Le chapitre 10, Modèles d'architecture de source de données, traite spécifiquement de la plupart des modèles les plus couramment utilisés pour les applications métier.
En général cependant, j'ai trouvé en utilisant l'approche la plus simple qui répond aux exigences de base de maintenabilité et d'adaptabilité est le meilleur choix.
Par exemple, sur un projet récent, une simple "Row Data Gateway" était tout ce dont j'avais besoin. (Il s'agissait simplement de classes générées par code pour chaque table de base de données pertinente, y compris les méthodes pour effectuer les opérations CRUD). Pas de débats interminables sur ORM par rapport aux procs stockés, cela a juste fonctionné, et a bien fait le travail requis.
Il existe plusieurs modèles courants. 'The patterns of enterprise architecture' livre est une bonne référence pour ces:
Si vous utilisez un ORM, comme LLBLGen, vous avez le choix entre un self-service ou un adaptateur.
Je me suis beaucoup appuyé sur Billy McCafferty's NHibernate Best Practices article/sample code pour de nombreuses applications Web/WinForms maintenant. C'est un article merveilleusement écrit qui vous fournira une bonne architecture d'échantillon solide - en plus de vous enseigner NHibernate et TDD de base. Il essaie de vous donner un aperçu de ses décisions d'architecture et de conception. Il crée une DAL très élégante à l'aide de DataAccessObjects génériques que vous pouvez étendre pour chaque objet de domaine - et il est très faiblement couplé aux interfaces utilisant BL et à un DAOFactory. Je recommande d'abord de regarder BasicSample, surtout si vous n'avez jamais travaillé avec NHibernate auparavant.
Notez cet article repose en grande partie sur NHibernate, mais je pense que l'approche générale pourrait être facilement modifié pour convenir à d'autres ORM.
Si vous descendez la route NHibernate (bon lien article BTW de @Watson ci-dessus), alors je vous recommande fortement de vérifier l'exemple de projet suvius-flamingo de codebetter. Il a une très belle, succinct, exemple de projet qui montre MVC et NHibernate en action.
Voici le suvius-flamingo link.
[mise à jour] ce n'est plus valide, la conception de ce projet a été modifié [/ mise à jour]
Dans notre projet open source Bunian, nous avons conclu que les objets d'affaires (le composant entier) est le noyau de le système, et tout devrait tourner autour d'elle, y compris cette couche d'accès aux données.
Le composant Business dictera aux autres ce dont il a besoin, ce qui implique que via itnerfaces. Par exemple Business Object La personne aura un membre d'interface appelé IRepositoryForPerson, ce membre sera assigné une instance via le conteneur Injection de dépendance si nécessaire.
Pour plus de détails vérifier mon blog ici:
http://www.emadashi.com/index.php/2008/11/data-access-within-business-objects-bunian-design//
et vérifier le code de Bunian ici (bien qu'il soit encore amateur):
http://www.codeplex.com/Bunian
Bien sûr, il poindra nouveau les choses avec cette approche comme le cycle de vie de la session d'accès aux données (si vous utilisez NHibernate par exemple). mais ce serait pour une autre question que je pense :)
j'espère que vous trouverez ce utile
Je vais supposer que vous voulez dire écrire une DAL qui accède à SQL, car cela est la partie la plus courante aujourd'hui. ON si le plus gros problème lors de l'écriture d'une DAL contre SQL est la partie ORM. C'est-à-dire qu'il existe une discordance d'impédance fondamentale entre la programmation OO et les schémas de base de données relationnelle. Il y a eu de nombreuses tentatives réussies, même réussies, d'écrire des ORM. Mais ils souffrent tous du même problème que leurs avantages: ils vous abstiennent du SQL sous-jacent généré. Pourquoi cela est un problème, c'est que la performance de votre base de données est un facteur critique de la façon dont votre système fonctionne globalement. Beaucoup ORM (peut-être la plupart) ont non seulement des performances médiocres pour de nombreuses requêtes standard, mais encouragent en réalité des modes d'utilisation qui dégradent considérablement les performances (traverser les relations à plusieurs reprises dans les boucles lorsque l'interrogation des collections est un exemple courant). un autre). Bien sûr, après avoir appris l'API ORM en détail, vous pouvez généralement trouver des moyens de contourner ces nids-de-poule de performance. Mon point de vue actuel sur l'état des ORM est que je veux qu'il fasse le moins possible, tout en me donnant l'efficacité d'une bibliothèque solide qui prend soin de tous les rouages de l'accès aux données. En d'autres termes, parce que je ne pense pas qu'ils soient "assez bons" pour le moment, et que je ne sois jamais avec SQL comme back-end, je veux garder le contrôle au niveau du bare-metal, et je vais écrire SQL par main dans la main sans hésitation, indépendamment de l'ORM, parce que je sais la manière spécifique dont je veux que les données soient interrogées pour mes besoins donnés. Il s'agit évidemment d'une approche de codage plus fragile que si vous utilisiez religieusement l'ORM comme prévu. Vous devez donc faire preuve d'une grande diligence en termes de tests unitaires, d'injection SQL et de séparation appropriée des préoccupations. . Donc, pour résumer, je suis d'accord avec Ash, bien que cela n'implique pas qu'il/elle soit d'accord avec moi :)
Je suis d'accord que pour des situations différentes la réponse sera différente, mais je suis à la recherche de différentes techniques et comment ils ont fonctionné. –