P: Como lidamos com trazer de volta campos de que não precisamos?

R: {[14] } pela minha experiência isto resume-se a lidar com entidades completas versus consultas ad-hoc.

Uma entidade completa é algo como um objecto User. Tem propriedades e métodos, etc. É um cidadão de primeira classe na sua base de dados.

Uma consulta ad-hoc devolve alguns dados, mas nós não sei qualquer coisa para além disso. À medida que os dados são transmitidos ao redor da aplicação, é feito sem contexto. É um...? A {[[0]} com algumas informações anexadas? Não sabemos.

Você está certo que muitas vezes irá trazer dados de volta que não irá usar, mas pode abordar isto de várias formas:

1. aggressively cache as Entidades de modo que você só paga o preço de leitura uma vez a partir da base de dados.
Passe mais tempo modelando suas entidades para que tenham boas distinções entre elas. (Considerar dividir uma grande entidade em duas entidades menores, etc.)
2. considere ter várias versões de entidades. Podes ter um para a parte de trás e talvez um para as chamadas do AJAX. Um pode ter 10 propriedades e um tem 3 propriedades.

Acaba-se com os mesmos dados em muitas consultas. Por exemplo, com um User, você vai acabar escrevendo essencialmente o mesmo select * para muitas chamadas. Uma chamada terá 8 de 10 campos, uma terá 5 de 10, uma terá 7 de 10. Porque não substituir todos por uma chamada que recebe 10 de 10? A razão disso é ruim é que é assassinato para re-fator / teste / zombaria. Torna-se muito difícil argumentar a alto nível sobre o seu código ao longo do tempo. Em vez de declarações como "por que o {[[0]} é tão lento?"você acaba rastreando consultas pontuais e então as correções de bugs tendem a ser pequenas e localizar. É muito difícil substituir a tecnologia subjacente. Se você armazenar tudo em MySQL agora e quer se mudar para MongoDB, é muito mais difícil substituir 100 chamadas ad-hoc do que é um punhado de entidades.

Q: terei muitos métodos no meu repositório.

R: {[14] eu realmente não vi nenhuma maneira de contornar isso, a não ser consolidar chamadas. O método chama em seu repositório realmente mapear para recursos em sua aplicação. Melhor características, As chamadas mais específicas de dados. Você pode empurrar para trás em recursos e tentar fundir chamadas semelhantes em um.

Uso as seguintes interfaces:

• Repository - carrega, insere, actualiza e apaga entidades
• Selector - encontra entidades baseadas em filtros, num repositório
• Filter - encapsula a lógica de filtragem

O meu {[3] } é agnóstico na base de dados; de facto, não especifica qualquer persistência; pode ser qualquer coisa: base de dados SQL, ficheiro xml, serviço remoto, um estrangeiro do espaço exterior, etc. Para procurar capacidades, o Repository constrói um Selector que pode ser filtrado, LIMIT - ed, ordenado e contado. No final, o selector obtém um ou mais Entities da persistência.

Aqui está um código de amostra:

<?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();
}

Então, uma implementação:

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);
    }
}

O ideea é que o genérico Selector USA Filter mas a implementação SqlSelector usa SqlFilter; o SqlSelectorFilterAdapter adapta um genérico Filter a um concreto SqlFilter.

O código do cliente cria Filter objectos (que são filtros genéricos) mas na implementação concreta do selector esses filtros são transformados em filtros SQL.

Outras implementações do selector, como InMemorySelector, transformem de Filter para InMemoryFilter usando o seu InMemorySelectorFilterAdapter específico; assim, cada implementação do selector vem com o seu próprio adaptador de filtros.

Usando esta estratégia, o código do meu cliente (na camada bussines) não se importa com um repositório ou implementação de selectores específicos.

/** @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. Esta é uma simplificação do meu verdadeiro código

#1 e 2

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

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

Se você quiser evitar uma ORM, então você teria que "rolar o seu próprio" para obter o que você está procurando.

#3

Em primeiro lugar, definimos modelos como um UserModel que usa um ORM para criar objectos UserEntity. Quando um UserEntity é carregado a partir de um modelo, todos os campos são carregados. Para campos referentes a entidades estrangeiras usamos o modelo estrangeiro apropriado para criar as respectivas entidades. Para essas entidades, os dados serão carregados à procura. A tua reacção inicial pode ser ...???...!!! deixe-me dar um exemplo um pouco de um exemplo:

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)
    {
        //...
    }
}

No nosso caso $db é um ORM capaz de carregar entidades. O modelo instrui o ORM a carregar um conjunto de Entidades de um tipo específico. A ORM contém um mapeamento e utiliza-o para Injectar todos os campos dessa entidade na entidade. Para campos estrangeiros, no entanto, apenas os IDs desses objetos são carregados. Neste caso, os OrderModel criam OrderEntity s apenas com os ids dos referenciados pedido. Quando PersistentEntity::getField é chamado pela OrderEntity a entidade instrui o seu modelo a carregar todos os campos para os OrderEntitys. Todos os OrderEntityassociados a uma Userentidade são tratados como um conjunto de resultados e serão carregados de uma vez.

A magia aqui é que o nosso modelo e ORM injectam todos os dados nas Entidades e que as entidades apenas fornecem funções de invólucro para o método genérico getField fornecido por PersistentEntity. Para resumir, carregamos sempre todos os campos, mas campos referentes a uma entidade estrangeira são carregados quando necessário. Apenas carregar um monte de campos não é realmente um problema de desempenho. Carregar todas as entidades estrangeiras possíveis, no entanto, seria uma enorme redução de desempenho.

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

Uma versão mais simples deste sistema seria passar a parte onde da consulta como uma string diretamente para o modelo.

Editar: para além disso, se realmente não quiser carregar alguns campos imediatamente, poderá indicar uma opção de carregamento preguiçosa no seu mapeamento ORM. Como todos os campos são eventualmente carregados através do método getField, Você poderia carregar alguns campos no último minuto quando esse método é chamado. Este não é um problema muito grande em PHP, mas eu não recomendaria para outros sistemas.

Número 1: demasiados campos

Este é um aspecto importante especialmente quando se tem em conta apenas os exames de índice . Vejo duas soluções para resolver este problema. Você pode atualizar suas funções para ter em um parâmetro de array opcional que conteria uma lista de colunas para retornar. Se este parâmetro estiver vazio, você devolverá todos os colunas na consulta. Isto pode ser um pouco estranho; baseado no parâmetro você pode recuperar um objeto ou um array. Você também pode duplicar todas as suas funções para que você tenha duas funções distintas que executam a mesma consulta, mas uma retorna uma matriz de colunas e a outra retorna um objeto.

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

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

Número 2: demasiados métodos

Outra solução estaria a usar __call() para mapear funções não definidas para algo accionável. O seu método seria capaz de analisar o findById e findByName em diferentes consultas.

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]
    }
}

Sugiro https://packagist.org/packages/prettus/l5-repository como fornecedor para implementar Repositórios/Critérios etc ... em Laravel5: d

Eu concordo com @ryan1234 que você deve passar em torno de objetos completos dentro do código e deve usar métodos de consulta genéricos para obter esses objetos.

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

Para uso externo/endpoint, gosto muito do método GraphQL.

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

Questão # 3: impossível corresponder a uma interface

Eu vejo a vantagem em usar interfaces para repositórios, para que eu possa trocar a minha implementação (para fins de teste ou outros). As a compreensão das interfaces é que elas definem um contrato que um a implementação deve seguir-se. Isto é óptimo até começares a adicionar métodos adicionais para os seus repositórios, como o findAllInCountry(). Agora Eu necessidade de atualizar a minha interface para também ter este método, caso contrário, outros implementações podem não tê-lo, e isso pode quebrar a minha aplicação. Isto parece uma loucura...uma caixa de cauda a abanar o cão.

O meu instinto diz-me que isto talvez precise de uma interface que implemente métodos optimizados de consulta, juntamente com métodos genéricos. As consultas sensíveis ao desempenho devem ter métodos específicos, enquanto as consultas pouco frequentes ou leves são tratadas por um manipulador genérico, talvez a despesa do controlador fazendo um pouco mais de malabarismo.

O genérico métodos permitiriam que qualquer consulta fosse implementada, e assim impediriam mudanças durante um período de transição. Os métodos específicos permitem otimizar uma chamada quando faz sentido, e ela pode ser aplicada a vários prestadores de serviços.

Eu acho que graphQL é um bom candidato em tal caso para fornecer uma linguagem de consulta em grande escala sem aumentar a complexidade dos repositórios de dados.

No entanto, há outra solução se você não quiser ir para o graphQL por agora. Usando um DTO onde um objecto é usado para marcar os dados entre processos, neste caso entre o serviço/controlador e o repositório.

Uma resposta elegante já está fornecida acima, no entanto eu vou tente dar outro exemplo que eu acho que é mais simples e pode servir como ponto de partida para um novo projeto.

Como mostrado no código, precisaríamos apenas de 4 métodos para operações CRUD. o método find seria usado para listar e ler através do argumento do objeto. Os Serviços de infra-estrutura poderiam construir o objeto de consulta definido com base em uma string de pesquisa URL ou com base em parâmetros específicos.

O objecto da consulta (SomeQueryDto) também pode implementar uma interface específica, se necessário. e é fácil de ser estendido mais tarde sem adicionar complexidade.

<?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;
    }
}

Uso de exemplo:

$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();