FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.

Home » Imported messages » comp.lang.php » Repository pattern implementation that knows nothing (Jon Snow) about the database table and column names
Show: Today's Messages :: Unread Messages :: Polls :: Message Navigator
| Subscribe to topic | Bookmark topic 
Switch to threaded view of this topic Create a new topic Submit Reply
Repository pattern implementation that knows nothing (Jon Snow) about the database table and column names [message #186366] Tue, 08 July 2014 11:47 Go to next message
qissolol is currently offline  qissolol
Messages: 1
Registered: July 2014
Karma: 0
Junior Member
add to buddy list
ignore all messages by this user
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?
Message by Jerry Stuckle is ignored  [reveal message]  [reveal all messages by Jerry Stuckle]  [stop ignoring this user] Go to previous messageGo to next message
Re: Repository pattern implementation that knows nothing (Jon Snow) about the database table and column names [message #186372 is a reply to message #186366] Wed, 09 July 2014 02:36 Go to previous message
Goran is currently offline  Goran
Messages: 38
Registered: January 2011
Karma: 0
Member
add to buddy list
ignore all messages by this user
On 8.7.2014. 17:47, qissolol(at)gmail(dot)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...)
Quick Reply
Formatting Tools:   
  Switch to threaded view of this topic Create a new topic
Previous Topic: schemadb oleata test it
Next Topic: Help with Pear Soap Client to weather service
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Thu Oct 03 09:45:01 EDT 2024

Total time taken to generate the page: 0.05243 seconds