ASP.NET: все на странице или взломать элементы управления?

Существует несколько причин, по которым вы можете использовать пользовательские элементы управления, например:

• Модульный код: вместо одного раздутого класса страницы вы можете разделить код на несколько пользовательских элементов управления, каждый из которых содержит меньше кода. Таким образом, если на вашей странице слишком много кода для управления, разделение его на пользовательские элементы управления может уменьшить размер каждого класса.
• Повторное использование: если один элемент управления используется на нескольких страницах или имеет несколько экземпляров на одной странице, гораздо проще создать его один раз, а затем повторно использовать несколько раз. Таким образом, если у вас есть общие компоненты пользовательского интерфейса, которые повторно используются во многих местах, вам могут помочь пользовательские элементы управления.

Конечно, за это приходится платить: каждый элемент управления должен предоставлять свойства, которые позволяют его родительским контейнерам управлять им, и он должен предоставлять события, чтобы уведомлять своих родителей о каком-либо событии. Родительские элементы управления также могут предоставлять аналогичные события и свойства, но это добавляет зависимость от родительского элемента управления в пользовательском элементе управления, что может усложнить повторное использование элемента управления в других контейнерах.

Если вы можете разбить многие части своей страницы на логические компоненты с четко определенным разделением ответственности, то они являются идеальными кандидатами для пользовательских элементов управления. Это похоже на то, когда вы определяете классы, и в какой-то момент класс может стать слишком сложным, и вы решите разделить его на несколько меньших классов, только здесь стоимость каждого нового класса, который вы определяете, выше.

По моему опыту, пользовательские элементы управления великолепны, просто не разбивайте свои элементы управления на такое количество уровней глубины, чтобы создать больше сложности, чем исходная раздутая страница. Попробуйте найти золотую середину, при которой элементы управления делают достаточно, а не слишком много, и у вас не слишком много элементов управления.

Вот несколько руководств по взаимодействию с пользовательскими элементами управления
http://www.codeproject.com/KB/user-controls/Page_UserControl.aspx
http://aspalliance.com/1461_Page_and_User_Control_Communication

Для моего первого приложения asp.net я использовал подход разделения на элементы управления. Однако я больше так не делаю, и теперь я просто помещаю все на одну страницу. Я бы использовал элементы управления только в том случае, если вам нужно повторить одну и ту же часть страницы и функции на нескольких страницах. Повторное использование — это действительно то, для чего предназначены элементы управления.

Если вы собираетесь использовать подход с несколькими элементами управления, вы можете использовать свойства, методы и/или события элементов управления, чтобы позволить им взаимодействовать друг с другом или с элементами управления на странице.

Пользовательские элементы управления облегчают повторное использование и, кстати, разбивают функциональность на более мелкие части, что упрощает управление кодовой базой. Вы также можете сделать это, тщательно спланировав свой код на одной монолитной странице, используя регионы и другие методы организации.

В прошлом я делал и то, и другое, и оба могут работать. Я считаю, что лучший способ связи между элементом управления и страницей - это события, т.е. при наличии страницы с BoxA (отображение сетки), BoxB (параметры сетки) и Grid (пользовательский элемент управления с представлением сетки в нем), BoxA может определить событие «DisplaySettingsChanged», который будет вызываться во время обратной передачи всякий раз, когда его настройки изменялись. Хостинг-страница будет создавать подписки на события между различными компонентами, например, захват DisplaySettingsChanged и вызов Grid.Refresh или что-то еще.

Что касается всей дополнительной инфраструктуры, если вы уверены, что не хотите повторно использовать какие-либо из этих компонентов где-либо, я бы, вероятно, поместил их на одну монолитную страницу с особым вниманием, чтобы все было организовано и удобочитаемо.

элементы управления должны отображать события, а страница должна обрабатывать их и соответствующим образом обновлять представление сетки.

Нарушение контроля основано исключительно на потребности. если вы хотите повторно использовать их, разбейте их на элементы управления. Если это похоже на второстепенный проект, нет необходимости в специальных элементах управления.

Есть 2 пути, по которым вы можете пойти -

Маршрут 1: получить одобрение от пользователя/заинтересованного лица/руководства/UAT, извлечь компоненты со страницы для лучшей управляемости, повторного использования и т. д.

Путь 2: Думайте о многоразовых компонентах с самого начала. Протестируйте свои компоненты/пользовательские элементы управления/пользовательские элементы управления/веб-части. Смешайте и сопоставьте свои компоненты на веб-странице и отправьте на утверждение.

В большинстве случаев у вас не должно возникнуть проблем с использованием Маршрута 1, особенно если ваши требования постоянно меняются, а у вас мало времени. Вы получите представление о требованиях к пользовательскому интерфейсу и проанализируете, разбиваете ли вы страницу на компоненты, требуется ли компонентам взаимодействовать напрямую друг с другом или через БД и т. д.

Маршрут 2 — это когда вы уверены, что у вас достаточно требований, чтобы указать, что определенный пользовательский интерфейс/поведение может быть повторно использован, потребует независимого тестирования и т. д.

Иногда не очень легко сразу перейти к маршруту 2. Если у вас есть опыт работы с доменом, то конечно.

Теперь в мире ASP.net вам даже нужно сделать выбор между пользовательскими и пользовательскими элементами управления. Это еще одно решение, которое вам, возможно, придется принять.

Надеюсь это поможет

Удачного кодирования!!

Я бы разбился на отдельные элементы управления только в том случае, если код будет использоваться повторно. В противном случае это просто пустая трата времени. Я также пытаюсь создать серверные элементы управления, если HTML-кодом нелегко управлять в режиме разработки, например код, который генерирует хлебные крошки или динамическую навигацию. Форма входа может быть хорошим примером пользовательского элемента управления.

Я работал над проектами с обеими крайностями: от всех функций, собранных на одной странице, до всех функций, имеющих специальный пользовательский элемент управления. Как минимум, я рекомендую сделать следующее:

• Дизайн всего сайта принадлежит вашим мастер-страницам
• Функциональность, отображаемая на двух или более страницах, должна быть заключена в пользовательский элемент управления. (Например, элемент управления входом может появиться в нескольких местах.)
• Другие функции прекрасно встраиваются в вашу страницу aspx.

Сложность заключается в правильном установлении связи, что может быть затруднено, если у вас есть глубоко вложенные слои элементов управления, которые должны взаимодействовать друг с другом, или когда у вас есть элемент управления на главной странице, который должен уведомлять элементы управления на дочерней странице (если они существует). Если вам нужна связь между двумя или более уровнями элементов управления, используйте следующую модель:

                ProxyNotifier
            /                  \
   Control1                      Control2

Другими словами, Control1 и Control2 имеют доступ к экземпляру ProxyNotifier. Control1 сигнализирует ProxyNotifer, а ProxyNotifer передает сигнал Control2.

Очень простая реализация будет выглядеть так: (ВНИМАНИЕ: непроверенный код, не предназначенный для промышленного использования):

public static class ProxyNotifer
{
    // NOTE: This delegate should NOT be held in a static variable since
    // its session specific
    private static Action<string> NotifyEvent
    {
        get
        {
            if (!Session.ContainsKey["ProxyNotifyEvent"])
            {
                Session["ProxyNotifyEvent"] = null;
            }
            return Session["ProxyNotifyEvent"] as Action<string>;
        }
    }

    public static void Subscribe(Action<string> handler)
    {
        NotifyEvent += handler;
    }

    public static void Unsubscribe(Action<string> handler)
    {
        NotifyEvent -= handler;
    }

    public static void Invoke(string msg)
    {
        if (NotifyEvent != null) { NotifyEvent(msg); }
    }
}


public class Control1 : UserControl
{
    void SomethingHappened()
    {
        ProxyNotifyer.Invoke("Hello world!");
    }
}


public class Control2 : UserControl
{
    public Control2()
    {
        ProxyNotifer.Subscribe(Respond);
    }

    // ALWAYS unregister your event when your control is disposed, 
    // otherwise weirdness happens
    public void Dispose()
    {
        ProxyNotifier.Unsubscript(Respond);
        base.Dispose();
    }

    public void Respond(string msg)
    {
        lblMsg.Text = msg;
    }
}

Теперь Control1 и Control2 могут общаться независимо от того, где они находятся на странице.