Hej Egna funderingar jag fått efter att blivit "kär" i extension methods är ngt man skulle kunna kalla method spamming ;) Något jag inte gillar är just hur extension plottrar ner i intellisense.. Se på IList, MASSOR för att få LINQ att fungera.. men vi har valet att inte ha med det om vi inte vill, och detta styrs med namespace, precis som du är inne på. För extension-metoden beskriven i grundartikeln blir det dock inte något egentligt problem. Det var en snygg variant av Databinding, absolut. Jag brukar köra med <%# %>, klart smidigast så :)Underlätta databindning med egna objekt - Feedback önskas
Har tagit mig tid att pilla ihop en artikel om att underlätta explicit databindning m.h.a. extension methods och generics här på Pellesoft.
Låt nu inte de tekniska namnen skrämma utan ta en kik på artikeln. :)
Den finns på http://www.pellesoft.se/area/articles/article.aspx?artid=1062
Jag önskar nu feedback på artikeln...
t.ex. i form av hur ni jobbar med egna objekt databundna mot kontroller?
Synpunkter på sättet/förfarandet som är beskrivet i artikeln
m.m
Kommentera då gärna denna artikel här i detta forum med så att det går att kommentera feedbacken i sin tur ;)
I den konstruktiva kritiken och argumenteringen ta då gärna med motivering VARFÖR ni tycker som ni tycker.
T.ex: Använd hellre vanliga Directcast, för att....(argument)Sv: Underlätta databindning med egna objekt - namespace spamming
dvs: Hur göra bra bibliotek/uppdelning av metoder så de inte spammar ens instanser i intellisensen?
En lösning är t.ex. m.h.a. att dela in dem (lägga in dem) i namnrymnder ( namespaces)
så man valbart kan välja att använda namnrymderna i sina kodklasser och då enbart få upp metoderna då. :-/Sv:Underlätta databindning med egna objekt - namespace spamming
extension methods - namespace spamming
Interfacet System.Web.UI.IDataItemContainer
är ganska hyffsat specifikt, dvs enbart i datakontroller typ gridview, repeater mm;
och enbart på dess container.
Denna arbetar man nog oftast (endast?) med där den används (i template-läge) så den orsakar (mig) inget problem.
Det generella med extensionmethods som jag skrev var just att de tenderade att som du senare beskriver att "plottra ned" intellisensen.
(spamma den).
Problemet blir lätt större när det blir mer generella datatyper som man påverkar, som säg integer, string.. eller varför inte...object!!?
Där/då kan man snacka om att det lätt kommer att förorena intellisensen.Intellektuell torka? databinda objekt web apps.
Känns lite skrämmande att så lite feedback inkommit på hur ni folk jobbar med datastrukturer/databindning
Eller använder så väldigt få utvecklare här på pellesoft egna objekt för att paketera data i webbapllikationer?
för även om man skulle använda ngn form av OR-Mapper, eller annat verktyg för att bunta ihop sitt data...
* NHibernate
* Linq 2 sql
* Entity framework
* t.o.m. typade dataset
Så kan man ju databinda dessa till datakontroller för webb, och det utan att använda EVAL *ryser*
; använder alla kanske alltid Bind?, eller är det så att folk använder SQLDatasource, AccessDatasource mm till att hämta data och presentera dessa, eller sitter ni på massa spännande lösningar men vill inte dela med er???
Som ett led till alternativa sätt att databinda data (dela med sig ;) ) i t.ex. en listview, mm
så kan följande sätt fungera bra... :D
För aktuell sida/usercontrol lägga till en egenskap, egenskapen returnerar typsäkrad data ( det man vill presentera/databinda) och blir iom detta ett slags kontrakt för vad sidan/kontrollen presenterar för data (~= är en vy av)
Protected ReadOnly Property Item() As MyClass
Get
Return DirectCast(Page.GetDataItem, MyClass)
End Get
End Property
På detta sätt kan man nu således använda detta i sina datakontroller:
ex1
<%# Item.Property.Xxxx %>
<%# Item.Property.Yyyy %>
ex2 (MyClass har i detta exempel en egenskap benämd Title)
<ItemTemplate>
<h1><%#Item.Title%></h1>
</ItemTemplate>
Mer info om Page.GetDataItem på MSDN
http://msdn.microsoft.com/en-us/library/system.web.ui.page.getdataitem.aspx
I en allmän kontext ( ej direktnämt),
man kan se hur en databunden kontroll använder metoden internt
http://www.manuelabadia.com/blog/PermaLink,guid,a2abee08-bb7f-4fe5-8a24-6e56da99172a.aspxSv: Underlätta databindning med egna objekt - Feedback önskas
Ska tänka på detta nästa gång jag nyutvecklar ASP.NET :)
Känns inte angeläget att skriva om allt det gamla där man använt det enligt dig förkastliga Eval osv. Jag har iofs aldrig sett några prestandaproblem pga av detta. Men visst är det mycket bättre om man kan vara typsäker! (Det var svårt att lösa detta på ett bra sätt när man började med .NET 1.0, delvis kanske pga att man inte kunde .NET lika bra då som man kan i dag). Är performance en stor grej då skriver man till en StringBuilder, så klart!! :) Jag har i princip endast använt Databinding för att binda datareaders till griddar. Annars föredrar jag att tilldela kontroller i kod. Det blir ju oftast inte mer kod än databinding/deklarativ kod ändå - plus att man får mer kontroll och kombinerar dataflytt mellan lager med validering, t.ex. man kanske måste göra en UpperCase av inmatade värden, osv.. Jag förstår inte riktigt poängen faktiskt med Databinding förutom då skapandet av listor. Jag tycker mest man abstraherar bort kontroll utan att vinna varken prestanda eller möjlighet att underhålla koden (för sakerna händer i den svarta lådan i stället för i den egna koden). Men i den mån man ska använda databinding tycker jag absolut att man ska göra som du föreslår här.Sv: Intellektuell torka? databinda objekt web apps.