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

Question

Когда вы создаете страницу, которая визуально разбита на определенные области, вы разбиваете эти области на элементы управления или все размещаете на странице и в одном коде?

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

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

Код для этого должен быть не менее пары тысяч строк.

Любые ресурсы по принятию этих типов проектных решений будут полезны.

Спасибо

Answer 1

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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

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

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

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

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

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

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

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

Счастливое кодирование !!

Answer 7

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

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