SPA 架构问题

Question

这篇文章旨在就网络单页应用程序展开更深入的讨论。在有关该主题的大多数资源中，有些问题似乎没有明确的答案。 他们在我的脑海里

1. 授权和认证。 由于整个 Web 应用程序都在客户端上，它可以在其任何功能中调用服务器，即使是那些用户无权访问的功能。用户看不到菜单这一事实并不妨碍该人调用 java 脚本函数。这在 MVC 应用程序中很容易处理，例如，通过使用基于 cookie 验证用户对特定功能的权限的控制器。但是，一些 SPA 应用只使用带有 Breeze 或 Web Api 的单个控制器，这使得授权服务器端无法实现。
2. 客户端的内存管理 对于小型示例应用程序，这不是问题，但想象一个具有 100 个屏幕的应用程序或一个具有单个屏幕的应用程序，它会在一天内提取数千条记录。有了持久缓存，人们可以想象会出现很大的内存问题，尤其是在 RAM 很少且功率不足的设备上，例如手机或平板电脑。如果没有明确的内存管理愿景，一群开发人员怎么可能拥有 SPA 路线？
3. 三层部署 一些 IT 部门永远不会允许带有连接字符串的应用程序连接到位于前端 Web 服务器上的数据库。我见过的每个 SPA 演示的结构都与此完全相同，包括 Breeze 或 Web Api。
4. 不显眼的验证。 它将要求开发人员使用 MVC 部分视图和控制器，而不仅仅是 HTML 文件，这似乎与 SPA 概念背道而驰，同时它提供了一种非常强大的方法来轻松地将验证和 UI 合并到 Web 应用程序中来支持它。李>
5. 在 url 中公开基于主整数的键。
   这在 OWASP 中是非否。 因此，SPA 应用程序“似乎”针对安全要求很少且功能集小的领域。你怎么看？

谢谢。

Answer 1

@Sergey - 我认为这对 StackOverflow 来说太宽泛了。所以。不是讨论论坛；这是一个寻求具体答案的地方。因此，尽管您的问题可能是有效的，但我认为您不应该对这里的深入实质性回答抱太大希望。

我想以最友好的方式补充一点，您的笼统、不受支持和负面的陈述使您看起来像一个巨魔。你不是巨魔是谢尔盖吗？

如果您确实担心，我会提供一些快速反应，尤其是与 Breeze 有关的情况。

1. 授权。在 Web API 中，您可以在方法级别进行授权。 ApiController 基类有一个User 属性，它返回IPrincipal。因此，无论您有一个控制器还是多个控制器（如果需要，您可以在 Breeze 中拥有多个控制器），粒度是方法级别，而不仅仅是类级别。

2. 内存管理。桌面开发人员多年来一直在应对这种担忧。如果您一直在开发进程生命周期很短的传统 Web 应用程序，这可能会让您感到惊讶。但是对于我们这些使用 WinForms、WPF 和 Silverlight 等桌面技术构建大型应用程序的人来说，长时间运行的流程并不是什么新鲜事。在 HTML 和 JavaScript 领域，问题和解决方案大致相同。

3. 后端层。你看演示太久了。是的，大多数演示将所有内容都转储到在一台服务器上运行的一个项目中。我们假设您知道如何重构服务器以满足您环境的扩展、性能和安全要求。我们的演示主要关注前端 SPA 开发。我们确实涉足了服务边界，以展示数据如何通过服务 API、ORM 和数据库流动。我们认为识别这些不同的层就足够了，并将这些层移动到不同层的相对琐碎的事情留给读者作为练习。有一天，我们可能不得不重新审视这个假设。但是有没有人认真地相信在服务器端层之间分配层/职责存在重大障碍？真的吗？像什么？

4. 不显眼的验证。当大多数人开始在 HTML 中使用“不显眼”这个词时，他们通常会强调将 JavaScript 排除在 HTML 之外。也许这也是您的意思，在这种情况下，各地的 SPA 开发人员都同意……这就是为什么有许多“不显眼的验证”库可用的原因。想到 HTML 5 验证、jQuery 验证和 Knockout 验证。所有这些都在 SPA 开发人员的工具包中，并且没有一个“要求开发人员使用 MVC 部分视图和控制器”。是什么让您觉得 SPA 需要任何类型的任何服务器端资源来使用无 JavaScript 的 HTML 标记实现验证？

5. 标识为安全风险。真的吗？这是假的。键值不比任何其他数据值更具安全风险。数以百万计的应用程序——不仅仅是 SPA——在 URL 和正文中向客户端传达键值。它是 REST API 中的标准。它是 ODATA 的标准。并且您想通过说它们“针对安全要求很少且功能集小的区域”来驳斥它们？祝你好运。我认为你必须做的更好，而不是把你的案子放在一个相对不起眼​​的组织的整个网站的链接上。

Answer 2

我已经构建了一些 SPA 应用程序，从小到大（超过 100 个脚本和视图）。他们中只有少数人拥有公众可以访问的所有视图。其余的经历了严格的访问结构。从服务器返回未经授权的 401 非常简单，客户端只需处理 401 即可将其重定向到登录屏幕。沃德先生和爸爸先生说得对。退出演示模式并尝试为您遇到的问题找到解决方案。我在复数视觉上观看了 John Papa 的 SPA，浏览了 Breeze 上的大量文章和应用程序，我必须告诉你，我的应用程序都没有使用 Breeze 从客户端进行查询，因为你不需要！！

此外，我只是扩展了我所学到的知识，并提出了我自己解决问题的方法。这不是您的问题的答案，但我只能提供一个简短的评论。没有一种技术是完美的，也没有一种方法可以做所有事情。我的服务器端被锁定在需要被锁定的地方，我在客户端的路由被锁定（如果使用 durandal 看看guardRoute），我的脚本被缩小并且我的图像被精灵化（如果有一个词像那）。总而言之，SPA 是一项很棒的技术，您必须找到解决问题的方法！