在线酒店预订项目 - 需要一些逻辑构建技巧来防止代码重复

Question

项目：在线酒店预订门户
页面：用户仪表板。 在这里用户可以添加属性和细节（基本细节、房间、设施等）

问题：在用户仪表板页面中，我们有几个页面（基本详细信息、政策、房间详细信息、图像等）。 每个控制器一个控制器。 对于每个控制器，我使用中间件VerifyPropertyUserMiddleware 。 现在我需要在每个控制器中获取属性模型。

$ppt = PropertyMaster::findOrFail($pID);

我能想到的解决方案

1. 在中间件中创建此实例并将其传递给控制器​​。 （但我认为中间件不应该做这项工作）
2. 创建一个特征，在该特征中创建一个方法getProperty （但代码重复仍然是一个问题，因为我必须在每个控制器中调用该方法）
3. 使用会话。 但是，代码重复仍然存在，因为在每个控制器中我都必须检查 laravel 会话是否有$ppt变量。

Answer 1

理想情况下（正如您已经提到的）您应该使用特征。 Traits 是一种为多个对象提供特定功能的美妙方式； 无需重复代码。

trait FindOrFail 
{
    public function getProperty(int $id)
    {
        return PropertyMaster::findOrFail($pID);
    }
}

然后在你的班级

class SomeOtherClass 
{
    use FindOrFail;

    ..... your code
}

Answer 2

这是用于在构造过程中丰富对象的特征示例。 这种特殊的丰富模式意味着当你的上游对象被实例化时，你将拥有与下游一起工作的所有荣耀，或者处理异常的属性。

trait PropertyAware
{
    private $property;

    private function loadProperty(int $id): void
    {
        $this->property = PropertyMaster::findOrFail($id);
    }
}

class PropertyFoo
{
    use PropertyAware;

    public function __construct(int $propertyId)
    {
        $this->loadProperty($propertyId);
    }
}

就在控制器上使用 trait 而言，我倾向于更喜欢边界操作并通过 contract 从 URL获取 Property 对象：

Route::get('dashboard/properties/{property}', function (App\Property $property) {
    // Use the hydrated $property.
});

这比使用特征（或在基本控制器上使用特征，这似乎很奇怪），然后将特征方法传递给 id 更有意义。

一般来说，我会建议私下应用丰富，也许将信封过程括起来，在传输过程中它是一个标识符，但是当消息被打开或应用时（如在 url 请求中），它会通过 trait 来丰富或丰富。

在这种情况下，扩充发生在 url 边界操作中，或者在解包以将消息传递给某种类型的处理程序（总线模式）时发生。 这里的尝试是自然解释为已知表示的瘦对象（例如，使用路由模型的控制器模式），或者可以取消引用其自身关系的属性字典对象（特征对象）。