web-dev-qa-db-fra.com

Motif de référentiel et requêtes de base de données

Ayant lu les messages des autres, il me semble déjà que le concept de " référentiel " et " base de données " ne vont pas bien la main dans la main, comme ils sont censés être des concepts complètement séparés .... mais je vais poser la question de toute façon.

J'ai actuellement importer différents types de données (un type de données peut se composer de plusieurs milliers de dossiers) de plusieurs bases de données qui se trouvent être tous différents (Oracle, Sybase, serveur SQL), processus que les données (selon le type de jeu de données est), puis d'écrire que les données traitées dans une autre base de données. La langue que je me sers est maintenant C #.

On m'a dit que l'utilisation du modèle référentiel dans ma situation pourrait être utile, mais je ne suis pas sûr comment ingénieur, et plus important encore, où placer toutes les différentes requêtes SQL paramétrées dans ce contexte. Ayant tant de différents produits et différentes sources de base de données ne contribue qu'à augmenter ma confusion.

Pour la raison mentionnée dans mon premier paragraphe, j'ai le sentiment que mes requêtes SQL doivent faire partie de ma couche d'accès aux données, alors que mes dépôts réellement vivent dans des couches ci-dessus. Est-ce que je reçois tout ce mal? Est-ce le modèle référentiel en fait une façon terrible de résoudre mon problème?

c#design-patternsdatabasepatterns-and-practicesrepository
7
Iliana

Mes 2 centimes: une base de données est une base de données. Un référentiel est quelque chose qui résoudra le concept de la base de données pour vous.

Lorsque nous disons une base de données, il s'agit directement de mots-clés tels que MS SQL Server, Oracle, DB2, MySQL, PostgreSQL.

Mais si vous développez un peu le concept, une base de données est un lieu où vous pouvez mettre des enregistrements, généralement de manière structurée et vous exécutez des requêtes contre ces enregistrements.

En ce sens, une base de données peut être un répertoire de votre système de fichiers, avec un tas de fichiers texte écartés, chaque fichier texte avec plusieurs lignes, chaque ligne représentant un seul enregistrement, par exemple.

Cela étant dit, quel est un référentiel alors? Un référentiel est un niveau d'abstraction plus élevé, au-dessus de la base de données. C'est là que vous stockez, récupérez et interrogeez des objets, d'un endroit magique, que votre demande peut ne pas être pleinement consciente.

Exemple de béton: disons que vous avez des enregistrements de 3 types différents: voiture, trafiquante et personne. Ils se rapportent les uns aux autres dans le schéma suivant:

  • Une personne a zéro ou de nombreuses voitures;
  • Une voiture a zéro ou de nombreux billets de circulation;

En outre, ils ont ces attributs:

  • Personne {Nom, SSN} = SSN est un identifiant unique.
  • Car {Ownersn, Plaque de licence} = La plaque d'immatriculation est un identifiant unique.
  • Traficticticket {ID, Plaque de licence, gravité, points, valeur} = ID est un identifiant unique.

Jusqu'ici tout va bien, non?

Maintenant, imaginez que vous avez une vaste base de données de tickets de trafic, fournie sous forme de fichier texte que vous pouvez télécharger depuis quelque part. Rien d'illégal, évidemment.

En outre, vous disposez d'une base de données Oracle dans la maison où vous avez une liste de personnes (chacune étant un employé de votre entreprise).

En outre, vous avez une liste de voitures que vous pouvez interroger à partir d'un partenaire qui vous a donné accès direct à sa base de données MySQL.

Votre responsable, un gars sympa - avec des antécédents éthiques ombragés - vous demande de faire de lui un rapport sur le nombre de ses employeurs ayant un mauvais enregistrement de conduite. Il souhaite utiliser cela pour tirer parti des places de stationnement dans le parking de la société et il vous menace de lui fournir ce rapport OR ...

L'intrigue se corse. Vous avez peu de temps pour faire votre rapport. Les factures de votre maison deviennent dû et vous avez une famille à élever (que va Little Ben sans ses céréales du matin?). Vous décidez donc de faire face au responsable ombragé et de le signaler au FBI plus tard. Après tout, c'est bien d'avoir un défi technique ici et là.

Vous décidez donc de créer un projet C #, car vous êtes intelligent, cool et vous savez LINQ-FU. Et vous structurez votre projet comme suit:

Espaces de noms:

ShadyReport.TextFiles.DAL
    TrafficTicketReader.cs
        public List<TrafficTicket> GetAllTrafficTicketsFromTextFile(string pathOfCompletelyLegalTextFile)

ShadyReport.Oracle.DAL
    EF6OracleContext.cs    *(your Entity Framework Oracle DB Context)*

ShadyReport.MySQL.DAL
    EF6MySQLContext.cs     *(your Entity Framework MySQL DB Context)*

ShadyReport.Repository
    PersonRepository.cs
        public List<Person> GetAllPersons()

    CarRepository.cs
        public List<Car> GetCarsOfPersons(List<Person> persons)

    TrafficTicketRepository.cs
        public List<TrafficTicket> GetTrafficTicketsOfCars(List<Car> cars)

ShadyReport.Entity
    TrafficTicket.cs *(simple POCO object)*
    Person.cs        *(simple POCO object)*
    Car.cs           *(simple POCO object)*

ShadyReport.Business
    ShadyReportGenerator.cs
        public void GenerateShadyReport()

Je suppose que vous savez comment travailler avec l'ensemble de l'entité et que vous comprenez que différents dBContexts peuvent avoir des connexions différentes, chacun indiquant une base de données différente.

Cela étant dit, c'est ainsi que votre méthode de votre GeneratesHadyRePort () ressemblerait à:

public void GenerateShadyReport()
{
    var personRepository = new ShadyReport.Repository.PersonRepository();
    var carRepository = new ShadyReport.Repository.CarRepository();
    var ticketRepository = new ShadyReport.Repository.TrafficTicketRepository();

    var persons = personRepository.GetAllPersons();
    var cars = carRepository.GetCarsOfPersons(persons);
    var tickets = ticketRepository.GetTrafficTicketsOfCars(cars);

    var shadyReport = <LINQ magic stuff to tie the objects above together>
}

Comme vous pouvez le constater, votre générateur de rapports ne sait rien d'où vient les données. Du point de vue du générateur de rapport, la base de données est un concept inexistant, car elle récupère les données des référentiels.

Cela étant dit, vos requêtes paramétrées spécifiques devraient aller dans vos référentiels spécifiques. Une requête qui filtre les voitures par des personnes doit être dans le référentiel de voitures, tandis qu'une requête qui lie les choses de différentes sources ensemble se fait dans la couche d'entreprise, au-dessus des référentiels. Voici comment ils ressemblent:

+-----------------+---+
| UI              | E |
+-----------------+ n |
| Business        | t |
+-----------------+ i |
| Repository      | t |
+-----------------+ y |
| DAL             |   |
+-----------------+---+

Et le graphique d'appels est toujours un moyen: en bas. UI appelle des affaires, qui appelle des référentiels, qui appelle dals. Et ils ont tous des entités "parlent".

J'espère que ça aide. Ce n'est pas la réponse définitive sur les référentiels, mais ces types de réponses m'aident généralement à comprendre les concepts.

5
Machado