[DC] Architecture Data Access Layer

Bonjour, me revoilà pour avoir vos avis concernant une partie de l'architecture de mon application développé en c# .net 2.0.

Pour résumer, la partie de mon application en question gère tout simplement une liste de contacts et d'événements qui se sauvegarde dans une bd SQL Server. L'application est monté en trois couche différente, soit le presentation layer, le business logic layer et le data access layer. Ces trois couches étant séparer par un namespace différent.

La partie d'architecture qui concerne mon message se trouve à être le Data Access Layer.

J'ai créer deux classes, soit Contacts_DAL.cs et Events_DAL.cs qui gère les requêtes sql pour les contacts et les événements. J'ai également créer une classe de base Base_DAL.cs qui contient le code nécessaire à la connexion à la base de données ainsi que pour l'éxécution des requêtes. Contacts_DAL et Events_DAL hérite de cette classe de base afin de ne pas avoir à spécifier le code de connexion à la bd dans toutes mes classes de mon data access layer.

Je voulais donc avoir votre avis sur cette façon de structuré les classes dans cette partie de mon application.

Bonjour !

Pourrais tu envoyé en petit schéma vite fait pour que nous puissions y voir plus clair ? Merci bien :)

Voici je joint la structure de mes classes en image.

Mais bon comme je n'ai jamais fait de uml je ne sais pas si tout est correct, les deux lignes pointillé signifie que Contacts_DAL et Events_DAL héritent de la classe Base_DAL.

Alors, puisque nous sommes dans le forum UML, autant corriger ton diagramme ;) :

- Les héritages sont représentés par des flèches pleines terminées par un triangle.

- Les implémentations d'interfaces par la même flèche, mais pointillée


Sinon, cela me parait plutôt bien. As tu regardé du coté du design pattern DAO (Data Object Access) ?

Attention, avec cet automatisme d'apporter pour tous les objets les méthodes CRUD : c'est bien et pratique, mais parfois insuffisant en termes de performances. Notamment, il est bien plus rapide d'effectuer des requêtes complexes avec de nombreuses jointures coté BD que dans le code. Ainsi, il peut être intéressant de construire des vues qui seront utilisées comme des objets "readonly"