Repository knows about database columns about designpatternsphp HOT 10 CLOSED

Having a Factory for each Entity/Storage implementation is a good solution?

from designpatternsphp.

Why do you have *Repository "orchestration" in your Domain layer?

from designpatternsphp.

Hi, can you please explain what you mean about *Repository "orchestration"?

from designpatternsphp.

sorry for not being clear.

For what i can understand from your diagram. Your FooRepository are just a simple Façade to the *Storage implementations, and Factories implementations. right?

they "orchestrate" the logic needed by your domain ("save/keep me that", "get me that Entity", "get me that Aggreggate", etc). I Called orchestration. sorry for the confusion.

example:

$userRepository->update($user);

// inside Repository
public function update (UserInterface $user)
{
    $id = $user->getUniqId();
    // $attributes - probably map your User Domain attributes to a associative array
    return $this->storage->update($id, $attributes);
}

from designpatternsphp.

What you think? Sounds good?

from designpatternsphp.

What it would be _get me that Aggreggate_?

from designpatternsphp.

Ok, lets set some starting point.

Let's consider some Domain-Driven-Design approach, and let's suppose that we've picked an application architecture like Hexagonal (also known as Ports and Adapters), or maybe the Onion Architecture.

With this in mind:

@malukenho Aggreggate is a very strong concept in DDD as Services, Repositories and Value Objects are, if not one of the most important ones..
I recommend you to google for it, and here is a starting point: http://dddsample.sourceforge.net/characterization.html

@leocavalcante your FooRepository implementations are coupled with your storage facility.
just move your FooRepository implementations to your infrastructure layer... get it outside of your domain layer. think about this "is storage a detail or a Domain concern to my application?" unless you creating some sort of application for a storage engine/specfication Repositories are outside of your Domain-concerns most of the time if not always.

So create a FooRepositoryInterface, INSIDE your Domain Layer.. that your INFRASTRUCTURE IMPLEMENTATION must adhere. And now you know that everytime a service in your domain/application layer, requests your dependency container for a FooRepositoryInterface, your implementation details comes from your infrastructure.

and in your infrastructure you can have classes like

class MongoDBFooRepository implements FooRepositoryInterface
{
 // details
}

class MySQLFooRepository implements FooRepositoryInterface
{
// details
}

You can if you like to inject and "have the coupling" to your physical persistence storage engines, in another abstraction layer with the implementations MYSQLStorage, etc. injected into your repositories, but then your Repositories will only look like Services, with a different name, don't they?

After all you'll have to have some object to be coupled with your Databases..

hope it help, and sorry for my bad english.

from designpatternsphp.

Ok, but the point is having a Repository implementation tied with a database schema.
Lets illustrate implementing MySQLFooRepository:

MySQLFooRepository implements FooRepository
{
    injectedConnection.query("SELECT id, name, email FROM users");
}

Sounds nice, right? It will return a object with id, name and email properties so I can create a User entity with that values. And it seams decoupled, right? I really can pass any other connection to MySQLFooRepository as long this connects to a database with the same schema!

MySQLFooRepository knows that the injected connection will query a database with a users table and id, name and email columns.

from designpatternsphp.

yes, sounds nice.

from designpatternsphp.

Please take a look at: http://leocavalcante.github.io/patterns/2014/07/11/repository-pattern-and-database-schema.html

from designpatternsphp.