0

我正在编写自己的 PHP MVC 框架，我想知道哪个地方最适合编写像User这样的持久数据对象。如果没有像 $_SESSION、APC、memcached 之类的持久性存储...有人可以在每次 http 请求时从数据库中检索用户数据，这在性能方面是个坏主意。(M) 模型似乎是一个不错的选择。像这样的事情是一个好的开始： 

class UserModel extends Model
{
  public function getEmail()
  {
    $user = Session::get('User');
    if(isset($user))
    {
      return $user->Email;
    }
    return null;
  }
}

可能不会，因为它没有返回大多数模型所做的数据库数据。我应该创建一个独立的类吗？这有什么模式吗？我不想让它全球化，谁是这些对象的所有者/管理者？

4

1 回答 1

2

您的模型应该只对业务逻辑进行建模。它们不应该与用户交互有任何关系。这是控制器（和视图）的工作。会话完全属于用户交互领域。所以不要在模型中使用它们。始终假设您将从命令行或其他不存在会话的上下文中使用模型。这应该会影响您的许多应用程序设计。

您可以在各个阶段实施缓存以减少主数据存储的负载。您应该有一个模型层或服务层，它表达了您的应用程序的核心逻辑。该层有一个定义的 API，您可以使用它在您的应用程序中执行操作。也许在幕后，该层使用 memcache 等在内部缓存一些数据以减少数据库的负载。
然后你应该有一个视图层，它从模型层获取数据并将其可视化。该视图层可能会缓存从模型层接收到的数据。

最大的收获：正确分离您的关注点。请参阅N-Tier Architecture - An Introduction，它可能会给您更多的想法。

于 2012-09-03T16:09:12.860 回答