Bazując na moim doświadczeniu, oto kilka odpowiedzi na twoje pytania:

P: jak radzimy sobie z przywracaniem pól, których nie potrzebujemy?

O: z mojego doświadczenia wynika, że naprawdę sprowadza się to do czynienia z kompletnymi podmiotami kontra zapytaniami ad-hoc.

Kompletny byt jest czymś w rodzaju User obiektu. Ma właściwości i metody itp. To obywatel pierwszej klasy w Twojej bazie kodów.

Zapytanie ad-hoc zwraca niektóre dane, ale nie wiemy wszystko poza tym. Gdy dane są przekazywane wokół aplikacji, odbywa się to bez kontekstu. Czy to User? User z dołączonymi informacjami Order? Nie wiemy.

Masz rację, że często przywozisz dane, których nie użyjesz, ale możesz się tym zająć na różne sposoby:

1. agresywnie buforuj encje, więc płacisz cenę odczytu tylko raz z bazy danych.
2. poświęć więcej czasu na modelowanie Twoje byty, więc mają dobre rozróżnienia między nimi. (Rozważ podzielenie dużego podmiotu na dwa mniejsze podmioty itp.)
3. rozważ posiadanie wielu wersji Bytów. Możesz mieć User dla back endu i może UserSmall dla połączeń AJAX. Jeden może mieć 10 Właściwości, a jeden ma 3 właściwości.

Wady pracy z zapytaniami ad-hoc:

1. otrzymujesz zasadniczo te same dane w wielu zapytaniach. Na przykład, za pomocą User, zakończysz up pisząc zasadniczo to samo select * dla wielu połączeń. Jedno połączenie dostanie 8 z 10 pól, jedno dostanie 5 z 10, jedno dostanie 7 z 10. Dlaczego nie zastąpić wszystkich jednym telefonem, który dostaje 10 na 10? Powodem, dla którego jest to złe, jest to, że morderstwo jest ponowne czynnik / test/wyśmiewanie.
2. z czasem bardzo trudno jest na wysokim poziomie rozumować o Twoim kodzie. Zamiast wypowiedzi typu " Dlaczego User jest tak wolno?"w końcu śledzisz jednorazowe zapytania, więc poprawki błędów są małe i zlokalizowane.
Naprawdę trudno jest zastąpić podstawową technologię. Jeśli teraz przechowujesz wszystko w MySQL i chcesz przenieść się do MongoDB, o wiele trudniej jest zastąpić 100 wywołań ad-hoc niż garstka podmiotów.

P: będę miał zbyt wiele metod w moim repozytorium.

Odp: [13] Wywołania metody w repozytorium naprawdę mapują do funkcji w aplikacji. Im więcej funkcji, tym więcej połączeń specyficznych dla danych. Możesz odepchnąć funkcje i spróbować połączyć podobne połączenia w jeden.

Czasami muszę sobie powiedzieć, " Cóż to musiało dać gdzieś! Nie ma srebrnych kul."

Używam następujących interfejsów:

• Repository - ładuje, wstawia, aktualizuje i usuwa encje
• Selector - wyszukuje encje na podstawie filtrów, w repozytorium
• Filter - enkapsuluje logikę filtrowania

Mój Repository jest agnostykiem bazy danych; w rzeczywistości nie określa żadnej trwałości; może to być cokolwiek: baza danych SQL, plik xml, usługa zdalna, obcy z kosmosu itp. Dla możliwości wyszukiwania, Repository konstruuje Selector, które mogą być filtrowane, LIMIT-ed, sortowane i liczone. Na końcu selektor pobiera jedną lub więcej Entities z persistence.

Oto przykładowy kod:

<?php
interface Repository
{
    public function addEntity(Entity $entity);

    public function updateEntity(Entity $entity);

    public function removeEntity(Entity $entity);

    /**
     * @return Entity
     */
    public function loadEntity($entityId);

    public function factoryEntitySelector():Selector
}


interface Selector extends \Countable
{
    public function count();

    /**
     * @return Entity[]
     */
    public function fetchEntities();

    /**
     * @return Entity
     */
    public function fetchEntity();
    public function limit(...$limit);
    public function filter(Filter $filter);
    public function orderBy($column, $ascending = true);
    public function removeFilter($filterName);
}

interface Filter
{
    public function getFilterName();
}

Następnie jedna implementacja:

class SqlEntityRepository
{
    ...
    public function factoryEntitySelector()
    {
        return new SqlSelector($this);
    }
    ...
}

class SqlSelector implements Selector
{
    ...
    private function adaptFilter(Filter $filter):SqlQueryFilter
    {
         return (new SqlSelectorFilterAdapter())->adaptFilter($filter);
    }
    ...
}
class SqlSelectorFilterAdapter
{
    public function adaptFilter(Filter $filter):SqlQueryFilter
    {
        $concreteClass = (new StringRebaser(
            'Filter\\', 'SqlQueryFilter\\'))
            ->rebase(get_class($filter));

        return new $concreteClass($filter);
    }
}

Ideea polega na tym, że rodzajnik Selector używa Filter, ale implementacja SqlSelector używa SqlFilter; SqlSelectorFilterAdapter dostosowuje rodzajnik Filter do konkretnego SqlFilter.

Kod klienta tworzy Filter obiekty (które są typowymi filtrami), ale w konkretnej implementacji selektora filtry te są przekształcane w filtry SQL.

Inne implementacje selektora, takie jak InMemorySelector, przekształcają się z Filter do InMemoryFilter używając ich specyficznego InMemorySelectorFilterAdapter; Tak więc każda implementacja selektora ma swój własny adapter Filtra.

Używając tej strategii mój kod klienta (w warstwie bussines) nie dba o konkretne repozytorium czy implementację selektora.

/** @var Repository $repository*/
$selector = $repository->factoryEntitySelector();
$selector->filter(new AttributeEquals('activated', 1))->limit(2)->orderBy('username');
$activatedUserCount = $selector->count(); // evaluates to 100, ignores the limit()
$activatedUsers = $selector->fetchEntities();

P. S. To jest uproszczenie mojego prawdziwego kodu

Dodam trochę na ten temat, ponieważ obecnie staram się zrozumieć to wszystko sam.

#1 i 2

class DbUserRepository implements UserRepositoryInterface
{
    public function findAll()
    {
        return User::all();
    }

    public function get(Array $columns)
    {
       return User::select($columns);
    }

Jeśli jednak chcesz uniknąć ORM, będziesz musiał "rzucić się", aby uzyskać to, czego szukasz.

#3

Interfejsy nie powinny być trudne i szybkie. Coś może zaimplementować interfejs i dodać do niego. To, czego nie może zrobić, to nie zaimplementować wymaganej funkcji tego interfejsu. Można również rozszerzyć interfejsy takie jak zajęcia, aby wszystko było suche.

[16]}mogę tylko skomentować sposób, w jaki (w mojej firmie) sobie z tym radzimy. Po pierwsze wydajność nie jest dla nas zbyt dużym problemem, ale posiadanie czystego/właściwego kodu jest.

Przede wszystkim definiujemy modele takie jak UserModel, które używają ORM do tworzenia UserEntity obiektów. Gdy UserEntity jest ładowany z modelu, wszystkie pola są ładowane. W przypadku pól odnoszących się do podmiotów zagranicznych używamy odpowiedniego modelu zagranicznego do tworzenia odpowiednich podmiotów. Dla tych podmiotów dane zostaną załadowane ondemand. Teraz Twoja początkowa reakcja może być ...???...!!! podam przykład:

class UserEntity extends PersistentEntity
{
    public function getOrders()
    {
        $this->getField('orders'); //OrderModel creates OrderEntities with only the ID's set
    }
}

class UserModel {
    protected $orm;

    public function findUsers(IGetOptions $options = null)
    {
        return $orm->getAllEntities(/*...*/); // Orm creates a list of UserEntities
    }
}

class OrderEntity extends PersistentEntity {} // user your imagination
class OrderModel
{
    public function findOrdersById(array $ids, IGetOptions $options = null)
    {
        //...
    }
}

W naszym przypadku $db jest ORM, który jest w stanie załadować byty. Model nakazuje ORM załadować zestaw jednostek określonego typu. ORM zawiera mapowanie i używa go do wprowadzania wszystkich pól dla tego encji do encji. W przypadku pól obcych ładowane są tylko identyfikatory tych obiektów. W tym przypadku OrderModel tworzy OrderEntity s tylko z identyfikatorami odwołanych rozkazów. Gdy PersistentEntity::getField zostanie wywołana przez OrderEntity, encja poleca modelowi leniwe ładowanie wszystkich pól do OrderEntity s. Wszystkie OrderEntity s związane z jednym użytkownikiem są traktowane jako jeden zestaw wyników i będą ładowane jednocześnie.

Magia polega na tym, że nasz model i ORM wstrzykują wszystkie dane do encji i że encje dostarczają jedynie funkcje wrappera dla ogólnej metody getField dostarczanej przez PersistentEntity. Podsumowując zawsze ładujemy wszystkie pola, ale pola odnoszące się do obcego podmiotu są załadowany w razie potrzeby. Samo ładowanie kilku pól nie jest tak naprawdę problemem z wydajnością. Załadować wszystkie możliwe podmioty zagraniczne jednak byłby ogromny spadek wydajności.

Przejdźmy teraz do ładowania określonego zestawu użytkowników, opartego na klauzuli where. Zapewniamy zorientowany obiektowo pakiet klas, które pozwalają określić proste wyrażenie, które można sklejać. W przykładowym kodzie nazwałem go GetOptions. Jest to opakowanie dla wszystkich możliwych opcji dla zapytania select. Zawiera zbiór gdzie klauzule, Grupa po klauzuli I Wszystko inne. Nasze klauzule where są dość skomplikowane, ale oczywiście można łatwo zrobić prostszą wersję.

$objOptions->getConditionHolder()->addConditionBind(
    new ConditionBind(
        new Condition('orderProduct.product', ICondition::OPERATOR_IS, $argObjProduct)
    )
);

Najprostszą wersją tego systemu byłoby przekazanie części WHERE zapytania jako ciągu znaków bezpośrednio do modelu.

Przepraszam za tę dość skomplikowaną odpowiedź. Starałem się podsumować nasze ramy tak szybko i klarownie, jak to możliwe. Jeśli masz jakieś dodatkowe pytania, możesz je zadać, a ja zaktualizuję mój odpowiedz.

EDIT: Dodatkowo, jeśli naprawdę nie chcesz od razu ładować niektórych pól, możesz określić opcję leniwego ładowania w mapowaniu ORM. Ponieważ wszystkie pola są ostatecznie ładowane za pomocą metody getField, można załadować niektóre pola w ostatniej chwili, gdy ta metoda jest wywoływana. Nie jest to zbyt duży problem w PHP, ale nie polecałbym innych systemów.

To są różne rozwiązania, które widziałem. Są plusy i minusy każdego z nich, ale to do ciebie należy decyzja.

Problem # 1: zbyt wiele pól

Jest to ważny aspekt, szczególnie jeśli wziąć pod uwagę skany tylko indeksowe. Widzę dwa rozwiązania tego problemu. Możesz zaktualizować swoje funkcje, aby przyjąć opcjonalny parametr array, który zawierałby listę kolumn, które mają zostać zwrócone. Jeśli ten parametr jest pusty, zwrócisz wszystkie kolumny w zapytanie. Może to być trochę dziwne; na podstawie parametru można pobrać obiekt lub tablicę. Można również zduplikować wszystkie funkcje, aby mieć dwie różne funkcje, które uruchamiają to samo zapytanie, ale jedna zwraca tablicę kolumn, a druga zwraca obiekt.

public function findColumnsById($id, array $columns = array()){
    if (empty($columns)) {
        // use *
    }
}

public function findById($id) {
    $data = $this->findColumnsById($id);
}

Problem # 2: zbyt wiele metod

Krótko pracowałem z Propel ORM rok temu i jest to oparte na tym, co pamiętam z tego doświadczenia. Propel ma możliwość generowania jego struktura klas oparta na istniejącym schemacie bazy danych. Tworzy dwa obiekty dla każdej tabeli. Pierwszy obiekt to długa lista funkcji dostępu, podobna do tej, którą aktualnie wymieniasz; findByAttribute($attribute_value). Następny obiekt dziedziczy z tego pierwszego obiektu. Ten obiekt potomny można zaktualizować, aby wbudować bardziej złożone funkcje gettera.

Innym rozwiązaniem byłoby użycie __call() do mapowania nie zdefiniowanych funkcji do czegoś możliwego do zastosowania. Twoja metoda __call będzie w stanie przetworzyć findById i findByName w różnych zapytaniach.

public function __call($function, $arguments) {
    if (strpos($function, 'findBy') === 0) {
        $parameter = substr($function, 6, strlen($function));
        // SELECT * FROM $this->table_name WHERE $parameter = $arguments[0]
    }
}

Proponuję https://packagist.org/packages/prettus/l5-repository jako sprzedawca do implementacji repozytoriów / kryteriów itp ... w Laravel5: d

Zgadzam się z @ryan1234, że powinieneś przekazywać kompletne obiekty w kodzie i używać ogólnych metod zapytań, aby uzyskać te obiekty.

Model::where(['attr1' => 'val1'])->get();

Do użytku zewnętrznego / końcowego bardzo podoba mi się metoda GraphQL.

POST /api/graphql
{
    query: {
        Model(attr1: 'val1') {
            attr2
            attr3
        }
    }
}

Problem # 3: niemożliwe dopasowanie interfejsu

Widzę korzyści w korzystaniu z interfejsów dla repozytoriów, więc mogę zamienić z mojej implementacji (do celów testowych lub innych). My rozumienie interfejsów polega na tym, że definiują one umowę, która wdrożenie musi nastąpić. To jest świetne, dopóki nie zaczniesz dodawać dodatkowe metody do repozytoriów, takie jak findAllInCountry (). Teraz Ja trzeba zaktualizować mój interfejs, aby również mieć tę metodę, w przeciwnym razie, Inne implementacje mogą tego nie mieć, a to może złamać moją aplikację. Przez to czuje się szalony...przypadek machania ogonem psa.

Moje przeczucie mówi mi, że może to wymagać interfejsu, który implementuje metody zoptymalizowane pod kątem zapytań obok metod ogólnych. Zapytania wrażliwe na wydajność powinny mieć ukierunkowane metody, podczas gdy rzadkie lub lekkie zapytania są obsługiwane przez ogólny handler, być może koszt kontrolera robi trochę więcej żonglowania.

The generic metody pozwoliłyby na implementację dowolnych zapytań, a tym samym zapobiegłyby łamaniu zmian w okresie przejściowym. Ukierunkowane metody pozwalają zoptymalizować połączenie, gdy ma to sens i może być stosowane do wielu dostawców usług.

Takie podejście byłoby podobne do implementacji sprzętowych wykonujących określone zoptymalizowane zadania, podczas gdy implementacje oprogramowania wykonują lekką pracę lub elastyczną implementację.

Myślę, że graphQL jest dobrym kandydatem w takim przypadku do zapewnienia języka zapytań na dużą skalę bez zwiększania złożoności repozytoriów danych.

Jest jednak inne rozwiązanie, jeśli na razie nie chcesz korzystać z graphQL. Za pomocą DTO, gdzie obiekt jest używany do przenoszenia danych między procesami, w tym przypadku między usługą/kontrolerem a repozytorium.

Elegancka ODPOWIEDŹ jest już podana powyżej, jednak postaram się podaj inny przykład, który moim zdaniem jest prostszy i może służyć jako punkt wyjścia do nowego projektu.

Jak pokazano w kodzie, potrzebujemy tylko 4 metod do operacji CRUD. Metoda find będzie używana do wyświetlania i odczytu przez przekazanie argumentu obiektu. Usługi zaplecza mogą budować zdefiniowany obiekt zapytania na podstawie łańcucha zapytania URL lub na podstawie określonych parametrów.

Obiekt zapytania (SomeQueryDto) może również zaimplementować określony interfejs w razie potrzeby. i jest łatwy do rozszerzenia później bez dodawania złożoności.

<?php

interface SomeRepositoryInterface
{
    public function create(SomeEnitityInterface $entityData): SomeEnitityInterface;
    public function update(SomeEnitityInterface $entityData): SomeEnitityInterface;
    public function delete(int $id): void;

    public function find(SomeEnitityQueryInterface $query): array;
}

class SomeRepository implements SomeRepositoryInterface
{
    public function find(SomeQueryDto $query): array
    {
        $qb = $this->getQueryBuilder();

        foreach ($query->getSearchParameters() as $attribute) {
            $qb->where($attribute['field'], $attribute['operator'], $attribute['value']);
        }

        return $qb->get();
    }
}

/**
 * Provide query data to search for tickets.
 *
 * @method SomeQueryDto userId(int $id, string $operator = null)
 * @method SomeQueryDto categoryId(int $id, string $operator = null)
 * @method SomeQueryDto completedAt(string $date, string $operator = null)
 */
class SomeQueryDto
{
    /** @var array  */
    const QUERYABLE_FIELDS = [
        'id',
        'subject',
        'user_id',
        'category_id',
        'created_at',
    ];

    /** @var array  */
    const STRING_DB_OPERATORS = [
        'eq' => '=', // Equal to
        'gt' => '>', // Greater than
        'lt' => '<', // Less than
        'gte' => '>=', // Greater than or equal to
        'lte' => '<=', // Less than or equal to
        'ne' => '<>', // Not equal to
        'like' => 'like', // Search similar text
        'in' => 'in', // one of range of values
    ];

    /**
     * @var array
     */
    private $searchParameters = [];

    const DEFAULT_OPERATOR = 'eq';

    /**
     * Build this query object out of query string.
     * ex: id=gt:10&id=lte:20&category_id=in:1,2,3
     */
    public static function buildFromString(string $queryString): SomeQueryDto
    {
        $query = new self();
        parse_str($queryString, $queryFields);

        foreach ($queryFields as $field => $operatorAndValue) {
            [$operator, $value] = explode(':', $operatorAndValue);
            $query->addParameter($field, $operator, $value);
        }

        return $query;
    }

    public function addParameter(string $field, string $operator, $value): SomeQueryDto
    {
        if (!in_array($field, self::QUERYABLE_FIELDS)) {
            throw new \Exception("$field is invalid query field.");
        }
        if (!array_key_exists($operator, self::STRING_DB_OPERATORS)) {
            throw new \Exception("$operator is invalid query operator.");
        }
        if (!is_scalar($value)) {
            throw new \Exception("$value is invalid query value.");
        }

        array_push(
            $this->searchParameters,
            [
                'field' => $field,
                'operator' => self::STRING_DB_OPERATORS[$operator],
                'value' => $value
            ]
        );

        return $this;
    }

    public function __call($name, $arguments)
    {
        // camelCase to snake_case
        $field = strtolower(preg_replace('/(?<!^)[A-Z]/', '_$0', $name));

        if (in_array($field, self::QUERYABLE_FIELDS)) {
            return $this->addParameter($field, $arguments[1] ?? self::DEFAULT_OPERATOR, $arguments[0]);
        }
    }

    public function getSearchParameters()
    {
        return $this->searchParameters;
    }
}

Przykładowe użycie:

$query = new SomeEnitityQuery();
$query->userId(1)->categoryId(2, 'ne')->createdAt('2020-03-03', 'lte');
$entities = $someRepository->find($query);

// Or by passing the HTTP query string
$query = SomeEnitityQuery::buildFromString('created_at=gte:2020-01-01&category_id=in:1,2,3');
$entities = $someRepository->find($query);

   class Criteria {}
   class Select {}
   class Count {}
   class Delete {}
   class Update {}
   class FieldFilter {}
   class InArrayFilter {}
   // ...

   $crit = new Criteria();  
   $filter = new FieldFilter();
   $filter->set($criteria, $entity, $property, $value);
   $select = new Select($criteria);
   $count = new Count($criteria);
   $count->getRowCount();
   $select->fetchOne(); // fetchAll();

Więc myślę