这是我见过的一些不同的解决方案。每一种都有利弊，但这是由你来决定的。

问题#1:字段太多

This is an important aspect especially when you take in to account Index-Only Scans. I see two solutions to dealing with this problem. You can update your functions to take in an optional array parameter that would contain a list of a columns to return. If this parameter is empty you'd return all of the columns in the query. This can be a little weird; based off the parameter you could retrieve an object or an array. You could also duplicate all of your functions so that you have two distinct functions that run the same query, but one returns an array of columns and the other returns an object.

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

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

问题2:方法太多

一年前，我曾短暂地与Propel ORM合作过，这是基于我对那次经历的记忆。Propel提供了基于现有数据库模式生成类结构的选项。它为每个表创建两个对象。第一个对象是一个很长的访问函数列表，类似于您当前列出的;findByAttribute (attribute_value美元)。下一个对象继承自第一个对象。您可以更新此子对象以构建更复杂的getter函数。

另一个解决方案是使用__call()将未定义的函数映射到可操作的函数。你的__call方法将能够将findById和findByName解析为不同的查询。

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

我希望这能有所帮助。

根据我的经验，以下是对你们问题的一些回答:

问:我们如何处理收回我们不需要的土地?

答:从我的经验来看，这实际上可以归结为处理完整实体与临时查询。

一个完整的实体类似于一个User对象。它有属性和方法等。它是代码库中的一等公民。

一个特别查询返回一些数据，但除此之外我们什么都不知道。当数据在应用程序中传递时，是在没有上下文的情况下完成的。它是用户吗?附带一些订单信息的用户?我们真的不知道。

我更喜欢与完整的实体一起工作。

你是对的，你经常会带回你不使用的数据，但你可以通过各种方式解决这个问题:

积极地缓存实体，这样您只需从数据库中支付一次读取代价。 花更多的时间建模你的实体，这样它们之间就有了很好的区别。(考虑将一个大实体分成两个小实体，等等) 考虑拥有多个版本的实体。你可以有一个User用于后端，也可以有一个UserSmall用于AJAX调用。一个可能有10个属性，一个有3个属性。

使用临时查询的缺点:

You end up with essentially the same data across many queries. For example, with a User, you'll end up writing essentially the same select * for many calls. One call will get 8 of 10 fields, one will get 5 of 10, one will get 7 of 10. Why not replace all with one call that gets 10 out of 10? The reason this is bad is that it is murder to re-factor/test/mock. It becomes very hard to reason at a high level about your code over time. Instead of statements like "Why is the User so slow?" you end up tracking down one-off queries and so bug fixes tend to be small and localized. It's really hard to replace the underlying technology. If you store everything in MySQL now and want to move to MongoDB, it's a lot harder to replace 100 ad-hoc calls than it is a handful of entities.

问:我的存储库中会有太多的方法。

答:除了整合通话之外，我还没有找到其他解决办法。存储库中的方法调用实际映射到应用程序中的功能。特性越多，特定于数据的调用就越多。您可以向后推功能，并尝试将类似的调用合并为一个。

一天结束的时候，复杂性必须存在于某个地方。使用存储库模式，我们将其推入存储库接口，而不是制造一堆存储过程。

有时我不得不告诉自己，“好吧，它必须在某个地方让步!”没有银弹。”

我将在此补充一点，因为我目前正试图掌握所有这些内容。

#1和2

这是一个完美的地方，您的ORM做繁重的工作。如果你正在使用一个实现了某种ORM的模型，你可以使用它的方法来处理这些事情。如果需要，可以创建自己的orderBy函数来实现Eloquent方法。举个例子:

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

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

你要找的似乎是ORM。没有理由你的存储库不能基于一个。这将需要用户扩展雄辩，但我个人不认为这是一个问题。

然而，如果您确实想避免ORM，那么您将不得不“自己滚动”以获得您想要的东西。

#3

接口不应该是硬性要求。可以实现接口并向其添加内容。它不能做的是未能实现该接口所需的功能。你也可以像类一样扩展接口来保持DRY。

也就是说，我才刚刚开始理解，但这些认识对我很有帮助。

我建议https://packagist.org/packages/prettus/l5-repository作为供应商来实现存储库/标准等…在Laravel5:D

我使用以下接口:

存储库——加载、插入、更新和删除实体 选择器——在存储库中基于过滤器查找实体 过滤器——封装过滤逻辑

我的存储库是数据库不可知的;事实上，它没有指定任何持久性;它可以是任何东西:SQL数据库，xml文件，远程服务，来自外太空的外星人等等。 对于搜索功能，存储库构造了一个选择器，可以过滤、限制、排序和计数。最后，选择器从持久化中获取一个或多个entity。

下面是一些示例代码:

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

然后，一个实现:

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

这个想法是，通用的选择器使用过滤器，但实现SqlSelector使用SqlFilter;SqlSelectorFilterAdapter将一个通用的Filter适配到一个具体的SqlFilter。

客户端代码创建Filter对象(通用过滤器)，但在选择器的具体实现中，这些过滤器在SQL过滤器中转换。

其他选择器实现，如InMemorySelector，使用它们特定的InMemorySelectorFilterAdapter从Filter转换为InMemoryFilter;因此，每个选择器实现都有自己的过滤器适配器。

使用这种策略，我的客户端代码(在业务层)不关心特定的存储库或选择器实现。

/** @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();

附注:这是对我实际代码的简化

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

所以我认为