Kończę duży projekt za pomocą Laravel 4 i musiałem odpowiedzieć na wszystkie pytania, które teraz zadajesz. Po przeczytaniu wszystkich dostępnych książek Laravel w Leanpub i mnóstwie googlowania, wymyśliłem następującą strukturę.

1. jedna wymowna Klasa modelu w tabeli datowalnej
2. jedna klasa repozytorium na wymowny Model
3. klasa usług, która może komunikować się między wieloma klasami repozytorium.

• Film
• Studio
• dyrektor
• aktor
• Recenzja

Klasa repozytorium hermetyzowałaby każdą wymowną klasę modelu i odpowiadałaby za operacje CRUD w bazie danych. Klasy repozytorium mogą wyglądać następująco to:

• MovieRepository
• StudioRepository
• DirectorRepository
• ActorRepository
• ReviewRepository

Każda klasa repozytorium rozszerzyłaby klasę BaseRepository, która implementuje następujący interfejs:

interface BaseRepositoryInterface
{
    public function errors();

    public function all(array $related = null);

    public function get($id, array $related = null);

    public function getWhere($column, $value, array $related = null);

    public function getRecent($limit, array $related = null);

    public function create(array $data);

    public function update(array $data);

    public function delete($id);

    public function deleteWhere($column, $value);
}

Klasa usług jest używana do klejenia wielu repozytoriów razem i zawiera prawdziwą "logikę biznesową" aplikacji. Kontrolery tylko komunikują się z klasami usług w celu utworzenia, aktualizacji i usunięcia działania.

Więc kiedy chcę utworzyć nowy rekord Filmowy w bazie danych, moja klasa MovieController może mieć następujące metody:

public function __construct(MovieRepositoryInterface $movieRepository, MovieServiceInterface $movieService)
{
    $this->movieRepository = $movieRepository;
    $this->movieService = $movieService;
}

public function postCreate()
{
    if( ! $this->movieService->create(Input::all()))
    {
        return Redirect::back()->withErrors($this->movieService->errors())->withInput();
    }

    // New movie was saved successfully. Do whatever you need to do here.
}

$data = array(
    'movie' => array(
        'title'    => 'Iron Eagle',
        'year'     => '1986',
        'synopsis' => 'When Doug\'s father, an Air Force Pilot, is shot down by MiGs belonging to a radical Middle Eastern state, no one seems able to get him out. Doug finds Chappy, an Air Force Colonel who is intrigued by the idea of sending in two fighters piloted by himself and Doug to rescue Doug\'s father after bombing the MiG base.'
    ),
    'actors' => array(
        0 => 'Louis Gossett Jr.',
        1 => 'Jason Gedrick',
        2 => 'Larry B. Scott'
    ),
    'director' => 'Sidney J. Furie',
    'studio' => 'TriStar Pictures'
)

Ponieważ Moviepository nie powinny wiedzieć, jak tworzyć nagrania aktorskie, reżyserskie lub studyjne w bazie danych, użyjemy naszej klasy MovieService, która może zobacz coś podobnego:

public function __construct(MovieRepositoryInterface $movieRepository, ActorRepositoryInterface $actorRepository, DirectorRepositoryInterface $directorRepository, StudioRepositoryInterface $studioRepository)
{
    $this->movieRepository = $movieRepository;
    $this->actorRepository = $actorRepository;
    $this->directorRepository = $directorRepository;
    $this->studioRepository = $studioRepository;
}

public function create(array $input)
{
    $movieData    = $input['movie'];
    $actorsData   = $input['actors'];
    $directorData = $input['director'];
    $studioData   = $input['studio'];

    // In a more complete example you would probably want to implement database transactions and perform input validation using the Laravel Validator class here.

    // Create the new movie record
    $movie = $this->movieRepository->create($movieData);

    // Create the new actor records and associate them with the movie record
    foreach($actors as $actor)
    {
        $actorModel = $this->actorRepository->create($actor);
        $movie->actors()->save($actorModel);
    }

    // Create the director record and associate it with the movie record
    $director = $this->directorRepository->create($directorData);
    $director->movies()->associate($movie);

    // Create the studio record and associate it with the movie record
    $studio = $this->studioRepository->create($studioData);
    $studio->movies()->associate($movie);

    // Assume everything worked. In the real world you'll need to implement checks.
    return true;
}

Lubię myśleć o tym w kategoriach tego, co robi mój kod i za co jest odpowiedzialny, a nie "dobrze czy źle". Tak rozbijam swoje obowiązki:

W przeciwieństwie do innych interfejsów API, procesory te nie są w stanie obsługiwać wszystkich interfejsów API.]}
• modele reprezentują schemat bazy danych i mówią aplikacji, jak wyglądają dane, jakie mogą mieć relacje, a także wszelkie globalne atrybuty, które mogą być konieczne (takie jak nazwa metoda zwracania połączonego imienia i nazwiska)
• repozytoria reprezentują bardziej złożone zapytania i interakcje z modelami (nie robię żadnych zapytań na metodach modelu).
• Wyszukiwarki-klasy, które pomagają mi budować złożone zapytania.

Mając to na uwadze, sensowne jest używanie repozytorium za każdym razem (niezależnie od tego, czy tworzysz interfejsy.itd. to zupełnie inny temat). Podoba mi się to podejście, ponieważ oznacza to, że wiem dokładnie, gdzie iść, kiedy jestem muszę wykonać pewną pracę.

Mam też tendencję do budowania bazowego repozytorium, zazwyczaj abstrakcyjnej klasy, która definiuje główne wartości domyślne-zasadniczo operacje CRUD, a następnie każde dziecko może po prostu rozszerzać i dodawać metody w razie potrzeby lub przeciążać wartości domyślne. Wstrzykiwanie modelu pomaga również ten wzór być dość solidny.

Pomyśl o repozytoriach jako o spójnej szafce na dane (nie tylko ORM). Chodzi o to, że chcesz pobierać dane za pomocą spójnego, prostego w użyciu interfejsu API.

Jeśli znajdziesz się po prostu robiąc Model::all(), Model::find(), Model::create() prawdopodobnie nie będzie wiele korzyści z abstrakcji z dala repozytorium. Z drugiej strony, jeśli chcesz zrobić trochę więcej logiki biznesowej do zapytań lub działań, możesz chcieć utworzyć repozytorium, aby ułatwić w użyciu API do czynienia z data.

Myślę, że pytałeś, czy repozytorium byłoby najlepszym sposobem radzenia sobie z niektórymi bardziej zwięzłymi składniami wymaganymi do łączenia powiązanych modeli. W zależności od sytuacji, jest kilka rzeczy, które mogę zrobić:

1. Zawieszając nowy model potomny z modelu rodzica (jeden-jeden lub jeden-wiele), dodałbym metodę do repozytorium potomnego coś w rodzaju createWithParent($attributes, $parentModelInstance), a to po prostu dodałoby $parentModelInstance->id do pola parent_id atrybutów i wywołanie twórz.

2. Dołączając relację wiele-wiele, w rzeczywistości tworzę funkcje na modelach, aby móc uruchomić $instance- > attachChild($childInstance). Należy pamiętać, że wymaga to istniejących elementów po obu stronach.

3. Tworząc powiązane modele w jednym uruchomieniu, tworzę coś, co nazywam bramką (może to być trochę odbiegające od definicji Fowlera). Sposób, w jaki mogę wywołać $gateway->createParentAndChild($parentAttributes, $childAttributes) zamiast trochę logiki, która może się zmienić albo to skomplikowałoby logikę, którą mam w kontrolerze lub komendzie.