2

我们团队中的一些人认为应用程序中的每个网页都应该是 Web 用户控件。因此，例如，您将在 Customer.ascx 中处理所有 html + 事件，并且将有一个包含 Customer.ascx 控件的相应 Customer.aspx 页面。

这些是他们的论点：

  1. 这种做法促进了多功能性、可移植性和可重用性。
  2. 即使该页面现在没有被重新使用，它也可能在将来被重新使用。
  3. 客户页面将来可能需要移动到不同的位置或重新命名，并且移动用户控件更容易。
  4. 这是 MS 对新开发的建议。

这真的是对新开发的建议吗？这种策略有什么缺点吗？我同意如果需要的话，手头有一个用户控件很好，但是对整个应用程序这样做似乎有点过头了，“以防我们以后需要它”。

4

4 回答 4

2

1、2 和 3：因为“你以后可能需要它”而做任何事情是一种可怕的策略。

http://c2.com/xp/YouArentGonnaNeedIt.html

4：我从未读过这篇文章，并且严重怀疑 MS 曾经说过这样的话。可能是某个拥有 MS 标签或 MVP 或其他人的随机文章，而一个容易上当的初级开发人员将其视为福音真理。

于 2008-11-11T01:23:41.333 回答
1

我曾经在 .NET 1.1 中遇到过这样编写的应用程序。一定有人听说过同样被误导的“最佳实践”，并将其视为绝对真理。

我同意它增加了大部分不需要的复杂性。我通常发现用户控件对于在多个页面上重复的页面部分更有用。如果您认为您会重复使用整个页面...为什么不直接使用原始页面？

我也不明白移动/重命名的论点。重命名/移动页面并不难。如果您按照同事的建议进行操作，您最终会得到一个只包含一个 orders.ascx 文件的 customers.aspx 页面吗？与仅重命名/移动文件相比，我看到这种方法更多潜在的混淆/错误。

于 2008-11-11T02:45:36.003 回答
1
  1. 严重地使客户端脚本复杂化，因为 NamingContainer jiggery 有时会将 _ctl0 等添加到所有内容中。
  2. 我认为MS从未推荐过它。请求 MSDN 文档的链接。
  3. 通常，当您完成实现某些东西并且它已经足够复杂时，当您尝试“重用”它时，您会发现很多“陷阱”。一个很好的例子是用户控件中的相对链接不再在其路径之外工作。
  4. 用户不需要在每个页面上添加/编辑/删除客户的能力。事实上，如果您在每个页面上都有这些类型的控件，您就会开始陷入缓存问题。例如，如果在发票页面上添加了客户，发票控件是否会更新为新客户？各种控件间的可操作性问题都会表现出来。这些问题都很难争辩，因为当然，每个人的用户控制都是完美的，所以这永远不会发生。哈哈对。
  5. 看看他们是否能想出一个例子，移动/重命名用户控件实际上节省了时间，而不是让它变得更复杂。绘制一个实际示例并展示每个示例的优缺点。
于 2008-11-10T22:43:52.013 回答
1

我个人不是粉丝，我认为它给应用程序增加了一层复杂性，这在早期阶段并不是绝对必要的。如果您需要重用一个您以前认为不会重用的组件，那么此时将其重构为用户控件应该不会很困难。

于 2008-11-10T22:49:24.373 回答