【问题标题】:How to handle passing data around internally within the app, in an PHP application?如何在 PHP 应用程序中处理应用程序内部传递的数据?
【发布时间】:2018-01-28 22:05:49
【问题描述】:

因此,如果我需要在应用程序内部传递数据,是否有很好的可预测方式来传递数据。

我希望能够查看一个函数并知道集合中传递给该函数的内容。

数组是一种不可预测的数据结构,所以你永远不知道你得到了什么。

我觉得用命名属性定义一个对象并将其传递给应用程序而不是数组会更好,因为这样就可以使用某种定义。

问题在于,在某个文件夹的某个地方只会有一堆对象堆积。

想知道任何人对此的看法,以及任何其他选择吗?

【问题讨论】:

  • “一堆对象堆积在某个文件夹的某个地方” - 您是否将它们存储为文件?你应该如何传递它们取决于你的应用程序,我们对此一无所知。一般来说,我更喜欢传递对象(称为值对象)而不是数组,因为您可以定义哪些属性应该可用。
  • 这一定是我读过的最模糊的问题。请提供一些实际背景。
  • 谢谢马格努斯。这正是我一直在寻找的。值对象。那么你把这些放在哪里呢?有关如何使用它们的最佳做法的任何建议?
  • “在哪里保存这些” - 这完全取决于您的应用程序结构。你可以把它们放在你想要的任何地方。关于“如何使用它们”,它们是对象,就这样使用它们......
  • @jonrsharpe 你是对的,它是模糊的。一个例子是,如果我有一个带有单个参数的函数,它是一个数组,该函数看起来像这样:public function ($some_array){}没有可预测的方法来知道该数组中的内容。但是如果 do:public function (CustomObject $some_object){}我可以查看该对象文件并知道传递给我的函数的内容。这就是 Magnus 调用的值对象。但是,我觉得文件夹中可能会堆积一堆值对象,因为每个不同的功能都可能需要一个新的值对象。

标签: php oop data-structures architecture system


【解决方案1】:

您可能遇到了更大的(尽管是隐藏的)问题。代码中的结构不应超过一层边界。

如果某个结构(无论是数组还是对象)跨越两层,那么除非是故意妥协,否则它是一个迹象,表明可能存在“架构缺陷”,表明其脆弱性你的代码库。这种跨领域的数据结构成为你的代码库出现重大错误的断层线。

如果你有跨越 3 层或更多层边界的结构,那么你的代码库就完蛋了。它成为那些“在它产卵之前用火杀死它”项目之一。

我使用的解决方案是这样的:

与其传递专用的“数据结构”,不如将您的业务逻辑集中在domain objects 上。您在层中的某个点创建它,您将实际使用它与逻辑相关的行为并将其注入或将其返回到其他层,只是为了影响它。

有点像这样:

public function loginWithPassword(Entity\EmailIdentity $identity, string $password): Entity\CookieIdentity
{
    if ($identity->matchPassword($password) === false) {
        throw new PasswordMismatch;
    }
    $identity->setPassword($password);
    $this->updateEmailIdentityOnUse($identity);
    $cookie = $this->createCookieIdentity($identity);

    return $cookie;
}

从这个方法中传入的不是一些“数据结构”,而是一个完整形成的逻辑实体,其中包含特定的、与业务相关的行为。

【讨论】:

  • 太棒了。我非常喜欢这个。而不是一些“抽象”数据结构,而是围绕更集中的领域特定对象传递。
  • 如果可以,可以。问题在于,实际上为您的域找出一个好的结构(并创建伴随的类)在最初几次是相当困难的。
猜你喜欢
  • 1970-01-01
  • 2011-04-24
  • 2015-09-05
  • 2013-08-14
  • 2013-12-15
  • 2010-10-29
  • 1970-01-01
  • 2019-03-26
  • 1970-01-01
相关资源
最近更新 更多