Custom Controls vs. Server Controls

Може ли някой да ми обясни, каква точно е разликата в ASP.NET между Custom Controls и Server Controls?

ако е това което си мисля че питаш едното е .ascx парче (html в него доста например) с възможен код бехайнд (съмнявам се това да не ти е ясно).

А другото е контрол подобен на тези които се намират в System.Web.UI.WebControls, само че си го пишеш ти, наследявайки System.Web.UI.Control. Компилираш го и после го регистрираш с таг префикс...
нещо от типа на (наизуст де):
<%@Register tagprefix="MyASP" namespace="MyCustomControls" assembly="MyCustomControls"%>
Доста мощно, може да разширяваш вградените контроли...

Mersi za otgovora!

Bъпроса не е "Custom Controls vs. Server Controls" открийте десете разлики, а кога Custom Controls и кога Server Controls да използваме? И отговора е много прост: когато функционалността предоставена от контролите във фреймуърка не ни е достатъчна, наследяваме и екстендваме или създаваме изцяло нов custom control. Custom control е extended Server Control. Е, как тогава ще ги сравнявате изобщо. Те се наричат server controls защото html-a който изобразява контрола се рендерира на сървъра. Code behind означава че зад aspx файла ти стои cs файл който съдържа самия код рендериращ html-a. А, custom controls e съкратено от custom server controls. Лично за мене един server control си е сървър контол, дали ще е писан от Microsoft (не-къстъм) или от мене или от Пешо (къстъм) е все тая. Разлика няма. Защото тебе като те хване музата и седнеш да си пишеш къстъм контроли ги пишеш по абсолютно същия начин по който някой гений от Майкрософт е написал техните контроли. Така че по-льеко с разликите


XM TurboCT .. where comfort meets power

ok, 10x

ако трябва да бъдем по-точни (дори в момента специално пуснах студиото да видя дали така са кръстени) отговора ми касаеше Web User Control (.ascx файл) и Web Custom Control (това което ти си описал и при което екстендваме вградените контроли). Между двете неща има доста разлика, и са определено подходящи за различни случаи...

> Code behind означава че зад aspx файла ти стои cs файл който съдържа самия код рендериращ html-a.

С това малко не съм съгласен... ама предполагам че просто не го разбирам точно така както си искал да го кажеш.

ето ти ги всички разлики:

[линк]

разликите са супер повърхностни и могат да се преодолеят с custom attributes ... а като архитектура и имплементация са абсолютно идентични

не гледай на нещата като user, виждай нещата като developer

за code behind: имаш aspx файл и cs файл. като извикаш метод на един обект от aspx файла, имплементацията на този метод се търси в cs файла. Тоест зад aspx файла ти стои cs файл който съдържа реалната имплементация на обектите които ползваш в aspx файла.


XM TurboCT .. where comfort meets power

мда, те хората са си го казали:

Good for static layout |VS| Good for dynamic layout

Макар че приятното на веб кустом контролс е точно това че можеш да си ги нашаткаш в едно асембли и да е ползваемо от всички апликации на машината.

Докато веб усер контрола е по-полезен за употреба при изграждането на презентацията - т.е. можеш да отделиш хедър/футър/меню парчетата в отделни ascx файлове при конструкцията на лейаута. Нещо като include, само че готиното му е че работи като самостоятелна бойна единица, с капсулирани методи и пропертита.

ПП. 100% си наясно с тези неща, по-скоро доотговарям на въпроса по горе...

Мнее съвсем. Или по скоро съвсем не.

User Control (ascx + codebehind) е подходящ за статични нужди или когато можеш логически да групираш няколко контрола в едно. Добър пример за първото е SiteHeader and SiteFooter User Control, а за второто - Login User Control, който съчетва TextBox (username), TextBox (password) and Button (submit), заедно с логиката за authentication в code-behind.

Custom Server Controls са building blocks на ASP.NET. Всички сървърни контроли на Майкрософт, които използваш във Visual Studio, са Custom Controls. Te наследяват пряко от System.Web.UI.Control (Placeholder, Repeater, Xml, LiteralControl) или от System.Web.UI.WebControls.WebControl (всички останали). Специфичното при Server Controls е, че предоставят доста по-добър дизайн-тайм (визуално представяне на пропертитата в Property Browser) и поддъжат едитори - WinForms бекенд с който в дизайн-тайм можеш да кажеш как да изглежда контрола във браузера. Също така можеш да сложиш иконка на контрола и да го добавиш към ToolBox-a на Вижуал Студиото (тези всичките неща не се поддържат от User Controls).

Цената на тази мощност обаче е голяма - Custom Controls се пишат доста трудно, като за целта трябва да си напълно нясно с целия control-lifecycle - тоест да си наясно кога точно и в какъв ред минават всичките events на контрола - OnInit, OnLoad, OnPreRender, OnRender, LоadPostData, LoadViewState, SaveViewState, etc. Докато в нормално ASP.NET програмиране (Page, User Controls) можеш да изкараш спокойно и само с ОnLoad event (Page_Load), при сървърни контроли ще ти се наложи да научиш как бачка фреймъурка отвътре, което не е никак малко, нито просто. Също така сам трябва да персистваш стейта на контрола over postbacks, като сериализираш statefull данните на контрола като XML или String във ViewState-a. И още доста неща... като цяло писането на Custom Controls е най-трудната част от ASP.NET и по-принцип по-добре да не се заемаш ако не ти е ясно за какво става дума.

радвам се ... обаче темата не е User vs. Server ... чети заглавието на темата


XM TurboCT .. where comfort meets power