Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #14079 > unrolled thread

Repository pattern implementation that knows nothing (Jon Snow) about the database table and column names

Back to article view | Back to comp.lang.php

Contents

  Repository pattern implementation that knows nothing (Jon Snow) about the database table and column names qissolol@gmail.com - 2014-07-08 08:47 -0700
    Re: Repository pattern implementation that knows nothing (Jon Snow) about the database table and column names Jerry Stuckle <jstucklex@attglobal.net> - 2014-07-08 12:17 -0400
    Re: Repository pattern implementation that knows nothing (Jon Snow) about   the database table and column names Goran <goran@nospam.com> - 2014-07-09 08:36 +0200

#14079 — Repository pattern implementation that knows nothing (Jon Snow) about the database table and column names

I've seen around the Internet and Github, implementations for the design pattern Repository that knows about database table and column names. I was think, if I want to work with the database as a plugin, that I can unplug and plug another respecting Open/Closed for the rest of my code, my repository should not know about the column names of the database I'm using. So how to implement this pattern in a way that it can transform the result from the database into a Entity of my domain, without knowing about the database table and column names?

As my main language is PHP, I saw that in Doctrine\ORM you can easily pass different yamls or xmls config files, mapping the column names to property names on the Entity, but... I cant be a hostage of a library implementation, if I want to implement raw PDO, or any other library for my repositories that doesn't make this hydration out-of-the-box, my implementation should do, so how?

[toc] | [next] | [standalone]

#14080

On 7/8/2014 11:47 AM, qissolol@gmail.com wrote:
> I've seen around the Internet and Github, implementations for the design pattern Repository that knows about database table and column names. I was think, if I want to work with the database as a plugin, that I can unplug and plug another respecting Open/Closed for the rest of my code, my repository should not know about the column names of the database I'm using. So how to implement this pattern in a way that it can transform the result from the database into a Entity of my domain, without knowing about the database table and column names?
> 
> As my main language is PHP, I saw that in Doctrine\ORM you can easily pass different yamls or xmls config files, mapping the column names to property names on the Entity, but... I cant be a hostage of a library implementation, if I want to implement raw PDO, or any other library for my repositories that doesn't make this hydration out-of-the-box, my implementation should do, so how?
> 

No, typically the repository DOES know about the table and column names
in the database; it's purpose is to separate the database definition
from the rest of the program so that only the repository depends on the
database.  Change the database and change the repository, but the rest
of the code remains the same.

Without knowing the database information, the repository would have to
query the database definitions and internally build a description of the
database.  This can easily be done (PhpMyAdmin, for instance, does it).
 However, what this doesn't tell the program is exactly what's in each
column and how tables are related.

For instance, take a simple example (shortened for brevity):

TABLE employee
   id
   last_name
   first_name
   ...

TABLE department
   id
   dept_name
   manager_id

TABLE employee_department
   employee_id
   department_id

Now, you want a list of all employees managed by "John Doe".  To a
person, constructing the query from the above definition would be
relatively easy.  But it would be very complex for a program to do.

This could be done, as you found, by passing descriptions of the
database.  But you don't want that.

All I can say is, good luck.  It's something which has been dreamed
about for years, but no one has been able to implement except in very
limited circumstances.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14085 — Re: Repository pattern implementation that knows nothing (Jon Snow) about the database table and column names

On 8.7.2014. 17:47, qissolol@gmail.com wrote:
> I've seen around the Internet and Github, implementations for the design pattern Repository that knows about database table and column names. I was think, if I want to work with the database as a plugin, that I can unplug and plug another respecting Open/Closed for the rest of my code, my repository should not know about the column names of the database I'm using. So how to implement this pattern in a way that it can transform the result from the database into a Entity of my domain, without knowing about the database table and column names?
>
> As my main language is PHP, I saw that in Doctrine\ORM you can easily pass different yamls or xmls config files, mapping the column names to property names on the Entity, but... I cant be a hostage of a library implementation, if I want to implement raw PDO, or any other library for my repositories that doesn't make this hydration out-of-the-box, my implementation should do, so how?
>

Yes, it's possible.

Firstly, you need to make a technology-agnostic model (no Doctrine 
annotations, etc.), then repository interface.

Later, you can plug in whatever you want. That plugs are implementations...

Let's say, one implementation could be made using Doctrine 2 ORM. 
Because your model is tech-agnostic, you can't use annotations to map 
it, but nothing stop you to use external XML maps. Beside mapping, you 
need to create a repository implementation using Doctrin 2 ORM. Here is 
the skeleton of such implementation:

class DoctrineUserRepository implements UserRepository
{
     private $doctrineRepository;

     public function __construct(EntityRepository $doctrineRepository)
     {
         $this->doctrineRepository = $doctrineRepository;
     }

     // ...
}

Only things you should keep in mind are technology limitations - you 
can't make naive model (without investigating Doctrine ORM limitations) 
because you will encounter those limitations later (inheritance quirks, 
compostite primary keys, value objects...)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web