ASP 与 ASP.NET（瘦客户端与胖客户端）

Question

这个问题困扰了我很久。我在东欧的一家小公司工作。我们主要为本地客户、网络应用程序工作，主要是 b2b 和 b2c-s。我们的互联网基础设施不是很好，所以我们经常遇到本地 isp 和主机的问题，这些主机位于拥有我们构建应用程序的信息系统的公司中。

我们使用的技术是 Microsoft IIS、SQL Server 和带有大量 Javascript 和 Ajax 的 ASP。作为一名学生和开发人员，我知道 ASP 已经过时并且不支持许多很酷和有用的东西，但我相信我们的代码做得非常好。而且我们也创建了非常快的应用程序（在没有分页（不要问）的情况下，在一页上不到 4.5 秒的时间内从表中提取 8000 行（不要问）非常快）。为此，我们使用了胖客户端方法并从 Javascript 中提取了最大值。那么，我们的问题是什么？

自然要迁移，顺理成章的一步就是ASP.NET。但是我们有对抗，从我们的胖客户端、迷你 Javascript 网格和组件，我们必须专注于服务器端和瘦客户端。

感谢您对此的看法。我们将通过使用 ASP.NET 和瘦客户端架构获得什么？更大的好处会补偿速度下降吗？许多参考文献都认为完整的逻辑应该在服务器上并且没有解释为什么（我很了解 MVC 并使用它）？

谢谢

Answer 1

使用 胖服务器 + 瘦客户端 方法，您需要的带宽和客户端资源会大大减少，因此您可以提高性能 - 但这不是您的主要关注点，如果我理解正确的话.

对于开发人员来说更重要的是：就软件技术而言，ASP.NET 比纯 ASP 至少进步了一代，这意味着它具有更简洁的架构以及更好的可维护性和可扩展性。就商业价值而言，这是开发商店最重要的一个因素（远比初始开发成本重要）...

Answer 2

胖客户端 - 嗯？这种古老的二分法。如果我理解正确，您的“胖客户端”是在浏览器和服务器端运行的一些繁重的 JavaScript 代码，您拥有经典的 ASP - 对吧？

如果是这种情况，则对“胖客户端”一词的解释是相当不寻常的。当我看到“胖客户端”时，我通常会想到客户端服务器应用程序——在某个数据库上运行的可执行文件。就 .NET 而言，这将是一个 WinForms 应用程序。

就 ASP.NET 而言，该技术的经典用途是构建 WebForms，它被认为是 WinForms 的 Web 模拟。使用这种方法，您可以使用控件构建表单服务器端 - 非常类似于构建 WinForms。页面中几乎没有执行代码——只有带有 WebControls 附加标记的 HTML。在某种意义上你可以称之为“瘦客户端”

有趣的是，越来越多的开发人员正在放弃这种方法 - 只需在 SO 上运行 JQuery 查找即可。而且他们中的许多人仍然使用 ASP.NET 服务器端。

对于经典 ASP - 恕我直言，它应该被掩埋。你会更好地为你的服务器端中继 21 世纪的东西，即 ASP.NET

Answer 3

旧的 ASP 会浪费您的时间。新的开发技术和库让您可以在传统 ASP 中浪费的时间中完成大事。当然，对于一次性的简单脚本，ASP 可能会带你，但一个完整的站点，不，谢谢。

无论如何...

我认为你是对的。我总是首先让一个网站以普通的、无 JS 代码运行。这确保它适用于不使用 JS 的人（可能对您来说不是问题），但以后在 AJAX 上分层并不难。

事实上，如果您愿意在组件上花钱（听起来您过去曾经这样做过），那么 AJAX.NET 有很多扩展可以将您从零 JS 带到可爱的页面。它们可能不像以前那样高效，但它们会更容易维护。

或者您可以在站点完成后在 AJAX 上分层。您甚至可以尝试保持从服务器到客户端的 API 与旧站点相同，以便您的旧 JS“正常工作”。

这显然不止一个最佳答案。

至于你的收获：在快速开发、更好的设计、显着改进的语言特性（毕竟 C# 和 VB.NET 是适当的编程语言）以及无需现在就可以做日常事情的能力方面有很多好处必须运行到第三方组件。

如果您想节省更多时间并减少基础架构和许可资金的全部负担，您甚至可以看看 Django 和/或 Ruby on Rails。

Answer 4

如果您对 ASP 经典感到满意，这意味着您不必尝试显着修改或扩展您的基本代码。如果你这样做了，你就会看到维护 ASP 的痛苦，尽管它本身就是一项强大的技术。

您还应该考虑其他几件事：1) 您的团队似乎非常精通 ASP，并且非常成功。如果没有真正令人信服的理由，为什么要改变？如果您更改技术，您的托管问题不会真正改善。 2) 从 ASP 到 ASP.NET Web 表单是一个非常重要的学习曲线。你的一些团队可能不会成功。这是一个真正的风险。但是，您确实应该将 ASP.NET MVC 作为一个选项进行检查。它与 ASP 经典有一些共同点，并且可能比 Web 表单更顺畅地过渡。

Answer 5

在我目前工作的公司，我们和您的职位相同。我要升级的几点是：

1. 易于调试。我必须花费数小时嵌套大量凌乱的 ASP 代码才能发现问题。我发现在 asp.net 或 .net MVC 中执行此操作要容易得多。

2. 兼容性。 Asp 是古老的，虽然仍然受到支持，但可能会证明升级是合理的。 .net over asp 的开发人员知识也更容易找到。

   话虽如此，我们并没有积极升级，因为这些应用运行良好。但是，您在 MVC 的正确轨道上，由于视图标记，asp 更容易通过 asp.net 升级到该平台。

Answer 6

在我回答之前，我想指出一点。

您不必放弃现有的客户端基础架构即可迁移到 ASP.NET！

虽然 ASP.NET Forms 的性能可能会下降，但 ASP.NET 中有更多可用的功能（除了 MVC）供您使用，而无需转换为 Forms。

与 ASP 页面相比，HttpHandler 具有相同的灵活性和更多功能。通过将 ASP 页面转换为代码语句并将页面内声明减少为输出语句，您可以将棘手的页面映射到 ASP.NET。根据您现有的设计，您甚至可能会发现很多现有工作的映射几乎是逐行重合的。

Creating HttpHandlers @ MSDN
IHttpHandler Interface @ MSDN

此外，如果您愿意，您可以将 .ASP 扩展处理程序重新映射到 .ASHX 处理程序以保留您的链接。您的客户端代码甚至可能不会注意到这种变化。

最后，除了关于瘦/胖客户端架构的任何争论之外，以下是我应该迁移到 .NET / ASP.NET 的主要原因。

1. 访问更好的 IDE（我希望您已经从 InterDev 继续前进！）
2. 大大改进了调试支持
3. 访问 .NET 特定功能。
4. 异常支持（而不是 OnError 语义）
5. 无需编写 COM 组件即可使用编译库。
6. 如果需要，可以使用 VB/VB.NET 以外的语言编写组件和页面处理程序。
7. 更好的身份验证支持，尤其是在 Negotiate/Kerberos 方面。