MVC 框架内的持久对象

Posted 2023-04-01

【中文标题】MVC 框架内的持久对象

【英文标题】：Persistent objects inside MVC framework

【发布时间】：2012-09-03 16:00:17

【问题描述】：

我正在编写自己的 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;
  

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

【问题讨论】：

拜托，不要写一个，那里已经有这么多的 php 框架了......你会浪费很多时间，而且学到的东西比你第一次学习如何现有框架试图解决常见问题和隐含的模式。如果还没有，请检查 Lithium/Symfony2。

@Olivier 我不同意。世界不需要另一个开源框架，没错。但是没有理由不使用专门针对您的需求量身定制的框架来滚动您自己的应用程序结构。

@deceze 我想你是对的关于建立一些私有的东西，但缺点是如此巨大和耗时（安全性，orm 层），它不会出现在我的脑海中，并且考虑到排名的操作，我认为需要一个公平的警告。

@Olivier 好吧，在使用了几个框架之后，在其中一个上构建而不是做一些量身定制的东西可能会花费更多的时间。问题是几乎没有任何框架提供真正的、正确的 MVC 设置。自己建造一个比试图将一个硬塞到现有结构中要少得多。不过，对于单个评论来说，这已经相当深入了...... :) 我同意，尽管新手最初在 some 预定义的结构中工作可能会更好，即使它不是最好的。跨度>

@Olivier 我知道那里有数百个 php 框架，其中一些很糟糕，另一些太复杂，难以理解，它们可能只能解决您的部分需求......这个这就是为什么我要编写自己的框架，以便与我的工作一起学习和发展。

【参考方案1】：

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

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

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