Laravel瘦控制器优化：AuthController登录逻辑迁移方案咨询

针对你想把登录逻辑从控制器移出的需求，以下是几种可行的优化方案，可根据项目规模和未来扩展性选择：

方案一：封装到User模型（领域模型模式） #

登录、密码验证、生成API Token这些行为本身属于用户实体的核心能力，直接封装到User模型里符合单一职责原则，代码内聚性更强。

实现步骤： #

在User模型中添加方法封装核心逻辑：

// app/Models/User.php
use Illuminate\Support\Facades\Hash;

public function verifyPassword(string $password): bool
{
    return Hash::check($password, $this->password);
}

public function generateAuthToken(): string
{
    return $this->createToken('AppToken')->plainTextToken;
}

// 可选：进一步封装完整登录校验逻辑
public static function attemptLogin(string $email, string $password): ?self
{
    $user = self::where('email', $email)->first();
    
    if (!$user || !$user->verifyPassword($password)) {
        return null;
    }

    return $user;
}

修改控制器的store方法：

public function store(StoreAuthRequest $request)
{
    $user = User::attemptLogin($request->email, $request->password);

    if (!$user) {
        return response(['message' => 'Bad credentials'], 401);
    }

    return response([
        'user' => new UserResource($user),
        'token' => $user->generateAuthToken()
    ], 201);
}

优点：代码简洁内聚，符合领域驱动设计思想，适合中小型项目。
缺点：若后续登录逻辑复杂化（如加验证码、第三方登录），模型会逐渐臃肿。

方案二：使用Service层封装 #

如果项目后续需要扩展复杂认证逻辑（如多端登录、登录日志、权限校验），将逻辑放到AuthService里能彻底解耦业务代码与控制器，让控制器只负责请求接收和响应返回。

实现步骤： #

1. 创建AuthService类：

// app/Services/AuthService.php
namespace App\Services;

use App\Models\User;
use Illuminate\Support\Facades\Hash;

class AuthService
{
    public function login(string $email, string $password): ?array
    {
        $user = User::where('email', $email)->first();

        if (!$user || !Hash::check($password, $user->password)) {
            return null;
        }

        return [
            'user' => $user,
            'token' => $user->createToken('AppToken')->plainTextToken
        ];
    }
}

2. 控制器通过依赖注入调用服务：

public function store(StoreAuthRequest $request, AuthService $authService)
{
    $result = $authService->login($request->email, $request->password);

    if (!$result) {
        return response(['message' => 'Bad credentials'], 401);
    }

    return response([
        'user' => new UserResource($result['user']),
        'token' => $result['token']
    ], 201);
}

优点：业务逻辑与控制器完全分离，便于扩展和单元测试，适合中大型项目。
缺点：小型项目会增加额外类文件，略显繁琐。

方案三：使用Action类（单一动作模式） #

Laravel社区常用Action类封装单一业务动作，每个Action只负责一件事（比如登录），代码拆分更细致，复用性和可测试性更强。

实现步骤： #

1. 创建LoginAction类：

// app/Actions/Auth/LoginAction.php
namespace App\Actions\Auth;

use App\Models\User;
use Illuminate\Support\Facades\Hash;

class LoginAction
{
    public function execute(string $email, string $password): ?array
    {
        $user = User::where('email', $email)->first();

        if (!$user || !Hash::check($password, $user->password)) {
            return null;
        }

        return [
            'user' => $user,
            'token' => $user->createToken('AppToken')->plainTextToken
        ];
    }
}

2. 控制器中调用Action：

public function store(StoreAuthRequest $request, LoginAction $loginAction)
{
    $result = $loginAction->execute($request->email, $request->password);

    if (!$result) {
        return response(['message' => 'Bad credentials'], 401);
    }

    return response([
        'user' => new UserResource($result['user']),
        'token' => $result['token']
    ], 201);
}

优点：单一职责极致化，代码复用性高，测试方便，适合复杂业务场景下的逻辑拆分。
缺点：会增加文件数量，小型项目无需过度设计。

总结 #

• 小型项目优先选User模型封装，简单高效；
• 中大型项目或有扩展需求时，选Service层或Action类，保障代码可维护性。

内容的提问来源于stack exchange，提问作者Shaun