ASP与ASP.NET (瘦客户端与胖客户端)
这个问题困扰了我很长一段时间。我在东欧的一家小公司工作。我们主要为本地客户、web应用程序工作，主要是b2b和b2c-s。我们的互联网基础设施不是很好，所以我们经常遇到当地的isp和主机的问题，这些isp和主机驻扎在拥有我们构建应用程序的信息系统的公司中。
我们使用的技术是Microsoft IIS、SQL Server和ASP，并使用了大量的Javascript和Ajax。作为一名学生和开发人员，我知道ASP很旧，不支持许多很酷和有用的东西，但我相信我们的代码做得很好。我们也创建了非常快的应用程序(在不到4.5秒的时间内，在一个页面上从表中读取8000行数据，没有分页(不要问)是非常快的)。为此，我们使用胖客户端方法，并从Javascript中提取max。那么，我们的问题是什么呢？
当然，我们必须迁移，逻辑步骤是ASP.NET，但我们有对抗，从我们的胖客户端，迷你Javascript网格和组件，我们必须专注于服务器端和瘦客户端。
我将感谢您在这方面的观点。我们将从使用ASP.NET和瘦客户端架构中获得什么？更大的好处是可以补偿速度下降的吗？许多参考文献都是教条式的，认为完整的逻辑应该在服务器上，但没有解释为什么(我很清楚MVC并在使用它)？
谢谢
回答 5
Stack Overflow用户
发布于 2009-11-20 01:57:45
在我开始回答之前，我想指出一些事情。
您不必为了迁移到ASP.NET而放弃现有的客户端基础架构！
虽然ASP.NET表单可能会降低性能，但ASP.NET中有更多功能(除了MVC之外)，您可以使用这些功能而不需要转换为表单。
HttpHandlers具有与ASP相同的灵活性和更大的功能。通过将ASP.NET页转换为代码语句，并将页内声明减少为output语句，可以将棘手的页映射到ASP语句。根据您现有的设计，您甚至可能会发现，许多现有工作的映射几乎是逐行重合的。
Creating HttpHandlers @ MSDN
IHttpHandler Interface @ MSDN
此外，如果需要，还可以将.ASP扩展处理程序重新映射到.ASHX处理程序，以保留您的链接。您的客户端代码可能甚至不会注意到这种变化。
最后，除了关于瘦/胖客户端体系结构的任何争论之外，这里是我应该迁移到.NET / ASP.NET的主要原因。
访问更好的集成开发环境(我希望您已经从InterDev!)
- Vastly改进的调试支持转向对特定于.NET的features.
- Exception支持的
- 访问(而不是在不编写COM components.
- Ability的情况下使用编译的库来使用VB/VB.NET以外的语言编写组件和页面处理程序，如果desired.
- Better身份验证支持，特别是在Negotiate/Kerberos.
方面
Stack Overflow用户
发布于 2009-11-20 01:32:47
使用胖服务器+瘦客户端的方法，您将需要相当少的带宽和客户端资源，因此可以提高性能-但如果我理解正确的话，这不是您主要关心的问题。
对于开发人员来说，更重要的是:在软件技术方面，ASP.NET至少比纯ASP早了一代，这意味着它拥有更干净的体系结构，更好的可维护性和可扩展性。就业务价值而言，这是开发商店最重要的一个因素(远比初始开发成本更重要)……
Stack Overflow用户
发布于 2009-11-20 01:37:03
胖客户端-哈？这是一种古老的二分法。如果我没理解错的话，你的“胖客户端”是在浏览器和服务器端运行的一些繁重的JavaScript代码，你有典型的ASP -对吧？
如果是这样的话，这是对“胖客户端”这个术语的不同寻常的解释。当我看到“胖客户端”时，我通常会想到客户端服务器应用程序--一个运行在某个数据库上的可执行文件。就.NET而言，这将是一款WinForms应用程序。
就ASP.NET而言，这项技术的经典用途是构建WebForms，它被设想为WinForms的网络模拟。使用这种方法，您可以在控件之外构建表单服务器端-非常类似于构建WinForms。实际上，页面中没有可执行的代码-只有带有WebControls附加标记的超文本标记语言。从某种意义上说，你可以称之为“瘦客户端”。
有趣的是，越来越多的开发人员正在远离这种方法--只要在这里运行JQuery的查找就可以了。而且他们中的许多人仍然使用ASP.NET服务器端。
对于经典的ASP - IMHO，它应该被埋没。您最好为您的服务器端转接21世纪的东西，即ASP.NET
https://stackoverflow.com/questions/1765030
复制相似问题
腾讯云开发者
