Методи за организиране на манипулатори на събития

Използвам asp.net и c# в уеб формуляри.

С помощта на Visual Studio той автоматично създава методи за обработка на събития за моите контроли. VS генерира името на метода по този начин idControl_event. Знам, че мога да дам произволно име на методите за обработка на събития.

  • Така че се чудя кой е любимият ви подход при именуване на тема.

  • Бих искал да знам дали с помощта на уеб формуляри е възможно да напиша метода за обработка на събития в отделен клас (не в кода зад конкретна уеб страница) и как да извикам тема от контрола.

Благодаря за отделеното време.


person GibboK    schedule 13.07.2011    source източник
comment
Просто от любопитство, защо бихте искали да отделите манипулаторите на събития от задния код?   -  person Tim    schedule 13.07.2011
comment
Прочетох този архитектурен подход в книга C# 2008 Objects, отнасяща се до модел, който може да се използва в Windows приложения. Основните идеи са да има обща логика на едно място за много контроли... така че ми беше интересно да видя дали може да се приложи дори в уеб формуляри.   -  person GibboK    schedule 13.07.2011
comment
Хм, това ми даде друга идея за използването на базов клас за капсулиране на общата логика - актуализирах отговора си, за да включа и тази опция.   -  person Stephen McDaniel    schedule 13.07.2011


Отговори (3)


За имена на манипулатори на събития обикновено използвам формата, който Visual Studio генерира по подразбиране: [idControl]_[eventName]. Но това до голяма степен е лично/отборно предпочитание. Виждал съм подобни дискусии за това като тази или този. Независимо от това как решите да наименувате манипулаторите на събития, мисля, че най-важното е да останете последователни.

Що се отнася до наличието на манипулатори на събития извън вашия код, не съм виждал това да се прави много често, но е възможно. Най-лесният начин би бил да имате статичен метод в отделен клас с обща логика за обработка на събития. Например, ето как можете да имате стандартна логика за Page.Loaded в отделен клас. Вярвам, че ще трябва да регистрирате манипулатора на събития чрез код - не мисля, че можете да го направите в маркиране (aspx).

public static class CommonEventHandlers
{
    public static void Page_Loaded(object sender, EventArgs e)
    {
        //Do any standard logic

        //If you need a reference to the page that raised the event, 
        //   you can get it from the 'sender' parameter.
        Page page = (Page)sender;

        //Do something with 'page'
    }
}

След това в задния код на страницата, която искате да използвате този общ манипулатор на събития:

public partial class WebForm1 : System.Web.UI.Page
{
    public WebForm1()
    {
        //Register the handler via code in the constructor
        Load += CommonEventHandlers.Page_Loaded;
    }
}

Като друга опция можете да използвате наследяването, за да помогнете с повторното използване на кода. Например, можете да имате базов клас, от който вашите страници наследяват и който има стандартни манипулатори. Едно предимство от това е, че можете да регистрирате манипулатори на събития в маркиране, дори ако методът е деклариран в базов клас, така че не е необходимо да правите нищо в кода зад страницата на предшественика.

person Stephen McDaniel    schedule 13.07.2011
comment
трябва ли OP също да настрои AutoEventWireup на false, за да използва това? - person Tim; 13.07.2011
comment
@Tim - AutoEventWireup няма да повлияе на този подход. Въпреки това, ако случайно имате метод, наречен Page_Load в страницата и AutoEventWireup е true, и този Page_Load метод и този в CommonEventHandler ще бъдат извикани. Но мисля, че това би било очаквано - и може би дори желано, в случай че искате да се появи стандартна обработка (в CommonEventHandlers) и персонализирана обработка (в Page_Load). - person Stephen McDaniel; 13.07.2011
comment
интересно Ако редът, в който са били задействани събитията, винаги е бил известен и гарантирано е същият (т.е. зад кода след това CommonEventHandlers), това може да доведе до някои интересни възможности за дизайн. Въпреки че все още не съм сигурен, че няма да има по-добри подходи там. - person Tim; 13.07.2011
comment
още обяснения за AutoEventWireup можете да намерите тук forums.asp.net/p/932513/1096656 .aspx - person GibboK; 13.07.2011
comment
На теория не вярвам, че поръчката е гарантирана. Но на практика манипулаторите на събития се извикват в реда, в който са регистрирани (само не ме цитирайте за това). Така че в случая по-горе първо ще бъде извикан 'CommonEventHandler' (той се регистрира в конструктора, което е много по-рано, отколкото когато се случи AutoEventWireup). Така или иначе, съгласен съм, че наличието на множество манипулатори на събития, които зависят от определен ред, е лош знак. - person Stephen McDaniel; 13.07.2011
comment
Благодаря, Стивън, разбирам, че посочвате използването на базов клас.. какви биха били плюсовете и минусите или и двата ви подхода? - person GibboK; 13.07.2011
comment
Единственият недостатък на използването на базов клас е, че C# няма множествено наследяване (което вероятно е хубаво нещо, но това е друга история). Така например, ако имате общ код, който искате да използвате и го поставите в BasePage като моя пример, това е добре, ако просто споделяте кода в други страници. Но тогава, ако искате да направите контрола, вече не можете да използвате BasePage като основен клас. Но освен това ограничение, мисля, че е по-чисто да се използват базови класове и просто се „чувства“ правилно :-). - person Stephen McDaniel; 14.07.2011

Не мисля, че можете да имате манипулаторите на събития в друг клас, най-доброто, което бихте могли да получите, вероятно би било в отделен файл с частичен клас

person Daniel Powell    schedule 13.07.2011

Както каза @Daniel Powell, почти съм сигурен, че най-доброто, което можете да направите със събитията, е да ги имате в различен файл като частичен клас за вашия код.

По отношение на конвенцията за именуване, в 95% от случаите виждам събития с име, както казахте - idControl_event. Това е начинът, по който ги назовавам, тъй като улеснява свързването на кода с контролата, когато гледам източника.

person Tim    schedule 13.07.2011