0

我们（我和我的团队）有一个大型网络项目，该项目将处理许多用户（至少 15,000 个用户！）。在细化阶段，我们决定以 MVC 风格进行编码。我们面临一个权衡（在这个项目中，所有操作都应该由经过身份验证的用户执行）。

一种设计方式可能是：控制器获取请求并根据它创建（从数据库加载）请求的负责对象，然后将该对象的引用保存到控制器，最后将控制器添加到会话用户。这种风格需要控制器是一个粗粒度的类，在用户可能的高频动作中具有多种行为。

另一种设计方式可能是：控制器获取请求，然后为请求创建负责的对象，但该控制器是无状态的，并且根据例如网站的一个页面具有特定的行为。通过这种方式，我们应该为每个页面创建一个控制器，如果它需要某些页面中常见的信息，我们必须从数据库或缓存中加载它们。

  • 在第一种风格中，控制器应该是一个粗粒度的对象，因为它减少了创建和垃圾收集，因此它只在用户通过身份验证后创建一次，并且在会话到期之前不会成为垃圾。会话中存在的对象的生命周期是直到会话过期，所以我认为这可能是导致内存不足的原因！
  • 在第二种风格中，每次用户切换到其他页面时，都应该创建一个控制器并从数据库中提取信息，这可能会导致性能问题！

我的要求：我想从内存使用和性能两个方面来比较它们！如果有任何建议，我会很乐意提及！

一个简单的例子请看下图：

http://v1.iimmgg.com/images/is7gr/fb0f6b763eea5294815dcb2d50a12f56.png

4

3 回答 3

0

实际上，从数据库访问的角度来看，在许多控制器中划分站点不会有什么不同，因为该对象在整个会话期间都得到了维护。在许多控制器中拆分站点并不意味着您要拆分会话。

于 2011-04-25T06:08:43.370 回答
0

大多数时候，您的数据访问层决定了系统的性能，而 mvc 应用程序中控制器的大小几乎没有影响。从设计的角度来看，我建议您将逻辑相关的操作保留在一个控制器中，这样您就可以拥有许多小型控制器。从性能的角度来看，您应该专注于您的数据库访问并找到它所属的优化。

于 2011-04-25T19:14:34.883 回答
0

我的经验法则是遵循REST 原则

每个企业实体都是一种资源。资源应该有控制器。

电子邮件、金钱等价值对象不是资源。

在少数情况下，当简单性超过复杂性时，应该合并控制器，额外的控制器会添加并且实体直接相关。

于 2011-04-26T11:51:26.413 回答