Discussion :

[Arthis]

Bonjour,

depuis quelques temps je m'interesse à cette facon d'aller chercher mes données dans une source de données, mais je bute un peu, car les discussions que je peux trouver sur le net sont d'un niveau déjà tres expert pour moi. Connaitriez vous un exemple utilisant ce pattern ou un lien permettant d'y faire ses premiers pas.

Merci d'avance,

[Paul Musso]

Bonjour,

Depuis quelle source veux-tu récupérer des données ? Sinon de quel pattern parles-tu ?

Sinon, voici un article montrant la création d'une DAL (lecture) en utilisant le pattern Template et les génériques.

[Arthis]

Je parle du repository pattern, que j avais mentionné dans le titre. Ce que j'en sais pour l instant est tres fragmentaire. Il s agirait de ce que j'ai pu en comprendre d'une facon d aller récuperer des donnés sans préciser si la source de donnés est une base de données ou un fichier xml, ou autre chose...

En fait, j ai déjà par le passé construit un ensemble avec couche d acces aux donnees, couches metiers, etc... MAis ce pattern semblait intéressant car il developpe une autre approche.

Comme je vais bientot commencer un nouveau projet, et par la meme une nouvelle architecture , j aurais voulu savoir de quoi il en retournait..


merci en tout cas pour ta réponse,

[Sylvain James]

Utiliser le pattern repository est un guideline recommandé globablement quelque soit le langage ou le framework, et on en trouve régulièrement des exemples dans ASP .NET MVC.

En effet il s'agit, lorsque l'on veut manipuler des données, de s'adresser à un point d'entrée, dont le code qui y accède ne connait pas la nature (SQL, XML, TXT, etc.) mais uniquement les services rendus.

Imagine le code contrôleur d'une page Index (extraction des données et présentation de ces données pour la génération de la page) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
public partial class HomeController : Controller {
 
        public ActionResult Index()
        {
            DataContext db = new DataContext();
            var allCustomers = from c in db.customers select c;
 
            ViewData["ListCustomers"] = allCustomers.ToList();
 
            return View("Index");
        }
}

Dans cet extrait de code, nous allons récupérer la liste des enregistrements de la table 'customers', à l'aide de Linq To SQL et l'injecter dans le pot de données ViewData, qui sera disponible dans la vue (Webform).

L'instanciation du context et l'extraction des données est 'en dur' dans notre méthode Index().

L'actualité concernant Linq to SQL confirme l'intérêt de s'appuyer sur le pattern repository. L'annonce récente de microsoft de concentrer ses ressources sur le framework Entitie au détriment de Linq to SQL : http://blogs.msdn.com/adonet/archive...s-roadmap.aspx a provoqué de nombreuses réactions dans la communauté des développeurs.

Quoiqu'il en soit, Microsoft va recommander sous peu d'utiliser le framework Entity comme couche d'accès aux données.

Revenons vers notre pattern repository :

Prévoyant de passer un jour à Linq To Entities, nous allons rendre notre code indépendant du moyen d'accès aux données...
Nous créons un nouveau fichier ICustomerRepository.cs dans lequel nous insérons un contrat, une interface :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
 
namespace MvcApplicationTest.Models
{
    public interface ICustomerRepository
    {
        IList<Customer> ListAllCustomers();
 
        void InsertCustomer(Customer c);
        void UpdateCustomer(Customer c);
        void DeleteCustomer(Customer c);
    }
}

puis un autre fichier CustomerRepository.cs qui intègre l'implémentation Linq To SQL de l'interface ICustomerRepository :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
namespace MvcApplicationTest.Models
{
    public class CustomerRepository_LinqToSQL: ICustomerRepository
    {
        private CustomerDataContext _datacontext;
 
        public CustomerRepository_LinqToSQL()
        {
            _datacontext = new CustomerDataContext();
        }
 
        public IList<Customer> ListAllCustomers()
        {
            var customers = from c in _datacontext.customers select c;
            return customers.ToList();
        }
 
        public void InsertCustomer(Customer c)
        {
            _datacontext.customers.InsertOnSubmit(c);
            _datacontext.SubmitChanges();
        }
// etc..
}

On peut convenir dès lors qu'il est possible d'écrire plusieurs implémentations différentes de l'interface ICustomerRepository. Une qui manipulerait les données dans un fichier texte, une autre dans un fichier XML etc.

Revenons à notre code initial, et au lieu d'insérer notre code Linq To SQL directement, nous allons nous adresser à une interface ICustomerRepository :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public partial class HomeController : Controller
    {
        private ICustomerRepository _repository;
 
        public HomeController() : this(new CustomerRepository_LinqToSQL())
        {
        }
 
        public HomeController(ICustomerRepository repository) {
            _repository = repository;
        } 
 
        public ActionResult Index()
        {
            //DataContext db = new DataContext();
            //var allCustomers = from c in db.customers select c;
 
            ViewData["ListCustomers"] = _repository.ListAllCustomers();
 
            return View("Index");
        }
...
}

Finalement, on n'a presque plus aucune dépendance à Linq To SQL dans notre code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

ViewData["ListCustomers"] = _repository.ListAllCustomers();

Pour ajouter de nouveaux services / méthodes, il suffit de compléter l'interface et son implémentation au fur et à mesure des besoins.

La seule dépendance restante se trouve au niveau du constructeur :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
public HomeController() : this(new CustomerRepository_LinqToSQL())
        {
        }
 
        public HomeController(ICustomerRepository repository) {
            _repository = repository;
        }

C'est à ce niveau que l'on va décider d'utiliser telle ou telle source de données avec la classe repository respective.
Par exemple si on a créé une classe qui manipule les données dans un fichier XML, il suffit de remplacer la classe CustomerRepository_LinqToSQL par une classe (qu'il nous revient d'implémenter en respectant l'interface ICustomerRepository), que l'on nommera par exemple CustomerRepository_LinqToXML :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
public HomeController() : this(new CustomerRepository_LinqToXML())
        {
        }
 
        public HomeController(ICustomerRepository repository) {
            _repository = repository;
        }

Le reste du code ne changerait absolument pas.
C'est particulièrement utile lorsque l'on effectue des tests unitaires et que l'on ne veut pas utiliser la 'vraie' source de données mais plutôt un jeu de données simple et rapide d'accès, et préparé à l'avance pour tous les tests.

Pour info, puisque le but du pattern repository est d'éviter toute dépendance, il existe des techniques pour supprimer la dépendance restance dans notre constructeur. C'est du domaine de ce que l'on appelle l'injection de dépendance (pattern IOC) qui s'effectue à l'exécution en fonction d'un paramétrage et non plus à la compilation codé en dur. Mais ce n'est pas forcément nécessaire d'en arriver là tout de suite :-)

Désolé j'ai pas réussi à faire très court, en espérant t'avoir éclairé.

Sylvain James

[Arthis]

Waow!!! merci pour tout!!

C'est exactement ce que voulais. Une introduction simple et pédagogique au repository pattern. Tu pourrais presque en faire un article d'introduction à ce pattern à mon avis.
En tout cas, Cela devient beaucoup beaucoup plus clair. Reste plus pour moi qu'à l'implementer un peu avant de poser de nouvelles questions.

Encore merci, et à bientôt,

Arthis

[Sylvain James]

Waow!!! merci pour tout!!

C'est exactement ce que voulais. Une introduction simple et pédagogique au repository pattern. Tu pourrais presque en faire un article d'introduction à ce pattern à mon avis.
En tout cas, Cela devient beaucoup beaucoup plus clair. Reste plus pour moi qu'à l'implementer un peu avant de poser de nouvelles questions.

Encore merci, et à bientôt,

Arthis

Tant mieux si j'ai pu t'aider ;-)
Pour l'article, c'est en effet une bonne idée !
Du coup, si tu as des questions, ça m'intéresse...

[C'est mon 500è post !] ca signe mon retour sur Developpez