无法理解C中的用户控件#

不要依赖父容器并不意味着你不能通信。在用户控件中公开父控件将设置的属性。但是有一个默认值,这样它就不会崩溃。

此外,如果这是一个非常具体的控制,那么没有理由不依赖父母。这可能不理想,但您将使用用户控件提供代码分离。

您的控件不需要知道数据来自何处。它不需要知道存储过程或其他任何信息。它只需要知道它需要显示的数据。如果我正确理解你的控制,它就是一个带有日期过滤器的网格。它将接收数据,显示数据并按日期过滤。很好,它只需要知道它需要显示的数据,可能还有来自父级的默认开始和结束日期。

如果你不允许用户控件与它的父控件通信,那么你就错过了它真正的强大功能。我认为在这种情况下,封装可能有点过头了。

假设您有一个用户控件,它只是一个表或各种用户数据的网格视图。不可避免的是,用户控件需要知道用户的唯一标识符,以便将其数据从任何位置提取出来,这当然会迫使您生成父页可以设置的公共属性。

此外,请记住,有时用户控件中的操作需要触发父控件上的操作。活动代理在这里起作用,它们非常有用,而且在我看来,它们使用户控件更加有用。

只需放弃关于用户控件和家长不来回交谈的全部想法,您就会发现事情变得容易得多。

所以,您在这个用户控件中有一些东西将数据绑定到存储过程返回的数据集?

以下是一种处理方法: 不要试图将存储过程与用户控件通信,而是使用户控件将依赖于用户控件的公共属性的数据集。

在运行时,用户控件之外的代码将运行相应的存储过程,并将用户控件上的DataSet属性设置为存储过程返回的结果。

正如其他人所指出的,您的用户控件需要有一种标准的方式来传达其意图和行为。这并不意味着您必须有一个对容器的引用,从而知道它实际上包含什么(mypage.aspx)。

在使用用户控件时,我发现不可或缺的是事件。学习事件以及如何使用它们。事件是沟通行为的一种很好的方式。

在您的示例中,我可以将您的条件(日期文本框)拆分为自己的用户控件。创建一个继承自EventArgs的新类,该类包含您的条件( DateTime 字段)。当用户单击搜索时,触发一个事件(类型为 EventHandler<YourEventArgs> )按照你的习惯 EventArgs . 页面将处理事件,查询数据库,然后将结果传递到第二个用户控件上的公共或内部方法,该方法显示记录。

如果需要调用不同的存储过程,可以在不同的页面上重用这里的键和条件控件。考虑插入与更新方案。通常,UI元素是相同的。您可以创建一个控件,并在具有两个不同行为(addrecord.aspx和updateRecord.aspx)的两个不同页上使用它。此外,显示记录的控件也很容易重用。

一个巨大的好处是你的页面和控件变得相当小。每个控件/页面实际上只关心其功能的一小部分。您的代码将变得不那么吓人,更容易维护。

“告诉”用户控件我要运行的存储过程

听起来你在找活动/代表
让控件公开一个事件,并让父级添加一个处理程序(如果您希望强制它添加一个且只有一个事件,则可能在构造函数中)
或者,可以使用命令/策略模式-让父级封装方法,并将封装对象发送到其构造函数中的控件。