我们正在开发一个 ASP.NET 应用程序。我们聘请了一家外部 UI 设计公司，并且在很大程度上对他们的工作非常满意。他们向我们“交付”的是可点击的屏幕——带有 ASPX 文件、图像、母版页等的 Visual Studio 解决方案。这些屏幕没有连接到任何数据源。他们有虚拟数据，这样我们就可以看到 UI 是如何工作的。
我们遇到的一个问题是我们的开发人员习惯于使用 Visual Studio 设计模式。当我们将它们拉入设计模式时，我们从 UI 公司收到的页面有时会出现问题。顾问的开发人员在不使用设计模式的情况下对这些屏幕进行编码。
我们假设他们会使用设计模式，但合同中没有具体说明。这是不是太过分了？是不是有很多 ASP.NET 开发工作从不经过 VS 设计模式？
建议：回答这个问题的人应该说明他们正在使用哪个版本的 Visual Studio，因为 Microsoft 废弃了 VS2005 和更早的设计器中的代码库，并将其替换为他们购买 Expression 产品时购买的代码库。两者完全无关，新的要好得多。-约翰桑德斯
您使用 Visual Studio 的次数越多，您对设计模式的依赖就越少。复杂的 UI 往往会使设计视图看起来很糟糕。
我（和同行）从不使用设计模式，原因有两个：
我在 VS 2003 中学会了不要触摸设计模式，因为您的 HTML 是由 VS 管理的。（虽然自 2008 年以来不再存在，但曾经被咬过......）
渲染可能需要很长时间。
从工具箱和手动代码拖放要快得多。
实际上，我发现使用设计器的 ASP.NET 开发人员非常少见。众所周知，Visual Studio 设计器不擅长生成干净的标记。
我从不使用设计模式，可能是因为它曾经把我的标记弄乱了。加上我做了很多动态渲染，所以没有意义。而且我只使用 CSS 进行格式化，我不希望 VS 乱来。
由于过去的糟糕经历，许多人从未使用过它。在使用现代控件时，我发现 VS2008 中的设计模式几乎没有问题，这些控件是最新的并且具有良好的设计器支持。
另一方面，由于早期的问题，许多自定义服务器控件没有良好的设计器支持，因此在设计模式中的用处要小得多，因为早期的设计器代码库已被一个好的设计器代码库替换。
我几乎从不使用设计模式。它通常会创建丑陋的 HTML，并称我为肛门，但我真的很喜欢干净的 HTML。如果这意味着手动编码，那就这样吧。
我更喜欢手动操作，我喜欢控制。
如果我想看结果，F5。
我几乎从不使用设计模式。对我来说，最大的原因是因为我在记事本中学习了网页设计/开发，所以我习惯（并且很舒服）使用代码。设计模式让我感到不舒服，因为我永远不确定 VS 会在 HTML 等方面做出什么决定。此外，我无法想象开发人员会使用设计模式来学习几乎同样多的 ASP.NET 和 VB/C# .
我唯一一次使用设计模式是自动配置 GridView 或类似的东西。
设计模式在这里受到了很大的打击，但让我指出它非常适合学习新控件。当您不熟悉 ASP.NET 或正在使用新的控件库时，设计模式是天赐之物，原因有两个：
当我第一次学习使用 Telerik 控件时，我非常依赖它们提供的智能标签，这些标签非常强大和完整。从中，您可以看到生成了什么样的 ASPX 标记并学习在设计模式之外工作。我是一个边做边学的人，所以在第一次使用某些东西时，我更喜欢这种方法来查看文档。
你知道，我什至从未意识到我 100% 的时间都在使用源屏幕。我通常在VS2005中开发。
每当我真正打开设计模式时，都是偶然的，我尝试在源视图呈现之前点击它。我从来没有对设计模式印象深刻，发现它很慢并且添加了很多不必要的标记。我还发现智能感知和属性窗口意味着我不需要 GUI 来开发。
当您尝试添加任何嵌套项目时，设计模式也可能是一场噩梦。因为我们一直在为使用 IE6 的客户进行开发，所以我们一直在使用表格进行格式化，因此我们不需要不同的 DIV 定义。仅单击空单元格可能会很困难，并且调整列的大小可能会花费很长时间。
对于网格中的模板字段之类的东西，我什至不知道如何在设计视图中进行设置！
话虽如此，每次都为 Windows 应用程序设计模式！
我使用的是VS2008，我从不使用设计视图。我发现代码视图比设计器更容易且响应更快。
设计模式越来越好，我想说随着时间的推移，它可能会变得更加普遍，并且设计模式工具会不断改进。我为设计模式设计了所有组件，但我仍然手动完成大部分代码 - 它允许更好地控制代码布局，并且最终不会产生自动格式化的混乱，然后我必须深入研究找出需要做出哪些改变。我知道将来我的组件可能会被开发人员使用，他们的大部分设计都是通过拖放完成的，现在解决这个问题比在活动结束后回来做更容易。
当然，我正在做 MVC 的东西，但我从不使用它——我是用 PHP 和代码编辑器“长大”的，它仍然对我很好。
我正在使用两个不同版本的 .NET（2003 和 2005）。2003年写的一些表格，2003年不能再编辑了，安装需要在2003年维护，所以我用KEDIT来编辑这些表格。一个应用程序中的某些表单对于 .NET 编辑器来说太大了，无论如何我更喜欢强大的编辑器。
我在设计模式下工作没有问题。一个例外是不支持的 asp:Repeaters，或者倾向于覆盖我的手动列定义的 GridViews。
另一种情况是，如果我重命名控件，VS 会尝试进行完整的项目扫描，然后失败。
我们主要使用代码视图。我们在 VS 2008 中发现的设计模式有很多错误。由于某种原因，XML 控件倾向于拒绝随机字符集，并且 VS 在尝试在屏幕上呈现所有内容时通常会运行缓慢。我主要使用代码视图。
传统上，WYSIWYG 设计人员生成的代码很差，CSS 和#INCLUDEd 文件的渲染也很差，因此它们的用途有限，因此开发人员倾向于手动编写代码。此外，这些工具允许您在不真正了解自己在做什么的情况下走一定的距离，这对于网络教程和个人主页来说很好，但是一旦您想要额外程度的控制，您就会陷入困境 - 当您有无论如何都要求助于“在引擎盖下”。
尽管工具随着时间的推移而改进，但许多开发人员对手工编码非常满意，以至于他们几乎忘记了设计视图——我当然不记得我上次使用它是什么时候了。我敢肯定，在很多情况下，此类工具可能真正有用，但我们在没有并且不想担心何时何地可以最好地使用此类功能时做得很好。
我们的 UI 很复杂，我们无法在 VS2005 中使用设计模式。
我唯一一次接触设计模式是做一个快速而肮脏的原型或内部应用程序。
我多久不使用设计模式？99% 的时间。