我们是否正在使用.Net 3.5中的MVC框架转向传统的ASP？
看着MVC框架，似乎我们需要更多的经典ASP知识，然后ASP.NET回发和Viewstates。我们是否在实际的前端HTML标记中向后移动到复杂的UI +代码逻辑？我们是否正在使用.Net 3.5中的MVC框架转向传统的ASP？
我们正在回避不要抽象掉HTML和HTTP请求等基本概念。在用户界面上，这意味着视图与输出更紧密地结合在一起，这不是一件坏事。将经典的ASP模型翻译成具有与输出紧密结合的一切，其中是的坏事。
这很有趣，你提到这个......我今天和同事进行了同样的谈话。
它是向后移动的一步吗？我不这么认为......虽然在经典的asp中，在UI中有一些复杂的逻辑，但从MVC中可以看出，复杂的逻辑应该仍然存在于业务对象中，并且与对象的任何复杂交互都应该通过控制器完成。
从我所能看到的目标来看，我们的目标是在实际的业务逻辑中保持UI的修剪和适合度。任何额外的膨胀都会导致使用户界面更友好，比如AJAX和JQuery。
这只是我关于MVC的初步观察。这是一项非常酷的技术，尤其是它在REST之上的地位，使得使用其他技术非常容易。
我期待在未来的几个项目中尝试它！
MVC的全部要点是代码分离。模型应该包含所有的业务逻辑，View应该只处理输出给用户，而Controller应该将这两个部分粘合在一起。
有人可能会争辩说，如果您认为ASP.NET范例向前迈进了一步，那么MVC范式是一个倒退。就我个人而言，我一直认为用传统的ASP编写干净的分离代码要容易得多，而不是使用标准HTML编辑器无法访问的显示输出文本通常被嵌入代码块的.NET。我一直认为ASP.NET架构更关注推动.NET，而不是改进应用程序的整体结构，因此从这个意义上说，MVC是向前迈出的一步。
如果您在视图中看到与模型和控制器相关的复杂代码逻辑，那么您可能以错误的方式接近它。
在纯粹的意义上，你应该能够以最少的工作将视图（XML而不是HTML）说出来。这只有在数据逻辑包含在模型中并且业务逻辑包含在控制器中时才会发生。
因此，如果您正在显示购物车，则该视图可能只有写出产品数量和总计的代码。模型类将保存产品数据，控制器将执行所有处理，如添加产品和检出。