相关疑难解决方法(0)

前言:我正在尝试在具有关系数据库的MVC架构中使用存储库模式.

我最近开始用PHP学习TDD,并且我意识到我的数据库与我的应用程序的其余部分非常接近.我已经阅读了有关存储库和使用IoC容器将其"注入"我的控制器的内容.很酷的东西.但是现在有一些关于存储库设计的实际问题.考虑以下示例.

<?php

class DbUserRepository implements UserRepositoryInterface
{
    protected $db;

    public function __construct($db)
    {
        $this->db = $db;
    }

    public function findAll()
    {
    }

    public function findById($id)
    {
    }

    public function findByName($name)
    {
    }

    public function create($user)
    {
    }

    public function remove($user)
    {
    }

    public function update($user)
    {
    }
}

问题#1:字段太多

所有这些find方法都使用select all fields(SELECT *)方法.但是,在我的应用程序中,我总是试图限制我获得的字段数量,因为这通常会增加开销并减慢速度.对于那些使用这种模式的人,你如何处理这个？

问题#2:方法太多了

虽然这个类现在看起来不错,但我知道在现实世界的应用程序中我需要更多的方法.例如:

• findAllByNameAndStatus
• findAllInCountry
• findAllWithEmailAddressSet
• findAllByAgeAndGender
• findAllByAgeAndGenderOrderByAge
• 等等.

如您所见,可能存在非常长的可能方法列表.然后,如果您添加上面的字段选择问题,问题就会恶化.在过去,我通常只是将所有这些逻辑放在我的控制器中:

<?php

class MyController
{
    public function users()
    {
        $users = User::select('name, email, status') …

Derik Whitaker 几天前发表了一篇文章,这篇文章引起了我一直好奇的一段时间:控制器中是否存在业务逻辑？

到目前为止,我见过的所有ASP.NET MVC演示都将存储库访问和业务逻辑放在控制器中.有些甚至在那里抛出验证.这会导致相当大的膨胀控制器.这真的是使用MVC框架的方式吗？看起来这最终会导致很多重复的代码和逻辑分散在不同的控制器上.

在ASP.NET MVC项目中为数据库实现Repository时,将业务逻辑放入其中是否正确,或者将逻辑放在控制器类中可能更好？或者使用其他服务和帮助程序类来操作数据？