[VS.NET 2005] SqlConnection, SqlCommand, etc. in designer

[VanRoyal]

Na voornamelijk met VS.NET 2003 en ASP.NET 1.1 te hebben gewerkt ben ik nu VS.NET 2005 en ASP.NET 2.0 aan het verkennen. Tot nu toe erger ik me helemaal kapot omdat de manier waarop ik (prettig) werkte, voor zover ik het heb kunnen ontdekken, niet meer mogelijk is. In VS.NET 2003 kon je bijvoorbeeld SqlConnections, SqlCommands, DataSets, etc. in je designer plaatsen, waarna je de properties kon bewerken. Zo was het heel eenvoudig om een command aan te maken obv een SP en werden de parameters netjes voor je aangemaakt. De objecten werden onderin de pagina getoond:



In VS.NET 2005 krijg ik dit met geen mogelijkheid voor elkaar. De objecten aan de toolbar toevoegen heeft geen zin, want ze zijn dan greyed out. Uiteraard kan ik ze nog wel gewoon in code behind declareren e.d., maar dan moet ik dus ook handmatig alle parameters aanmaken en dat vind ik persoonlijk nogal zonde van mijn tijd

Een andere oplossing zou het gebruik van het SqlDataSource object zijn, maar voor zover ik heb kunnen zien en lezen moet ik daar zo ver vandaan blijven als mogelijk (te clunky, sql code in je html page, etc.).

Weet iemand hoe ik toch in de designer de 'oude' objecten kan gebruiken, of zit ik vast aan de SqlDataSource en/of alles in code behind met de hand doen?

[EfBe]

Kan niet, in vs.net 2005 is het concept 'control on canvas' helemaal niet aanwezig. Je kunt dus geen connection etc. slepen op je page.

Op zich niet erg, want het plaatsen van een connection etc. object op een webpage leidt veelal niet tot onderhoudbare software.

[VanRoyal]

De connectiestring zelf staat in de web.config, dus feitelijk maakt het niets uit of je het SqlConnection object naar de pagina sleept of hem in code behind aanmaakt. Zelfde geldt voor alle andere objecten, het enige dat VS doet is de objecten voor je declareren in de code behind zodat je dat zelf niet meer hoeft te doen. Scheelt een hoopt tijd en werk. Voor de onderhoudbaarheid van een applicatie is er dus geen verschil.

Ik zag trouwens dat het in winforms wel gewoon werkt, dus waarom ze het er in webforms uit hebben gesloopt is mij een raadsel

Wat is dan een 'best practice' om met data om te gaan? Ik ga toch niet een heel SqlDataSource object aanmaken als ik een dropdownlijstje wil vullen met wat data? Zoals MS het nu presenteert is dat wel wat ze willen...

[EfBe]

De datasource controls zijn in feite de controller voor de data (model) en de viewer (page). Dus je plaatst een datasource op je page en daarmee bouw je je pagina's. Die datasource controls moeten dan de mogelijkheid geven om aan de ene kant gewone html te schrijven zonder code en aan de andere kant je de mogelijkheid geven om in een BL class of code behind de fetch code te schrijven. Het voordeel ervan is dat je nu 2-way databinding hebt, dat had je niet.

[VanRoyal]

Het is een enorme kick, maar door gebrek aan tijd heb ik VS 2005 en ASP.NET 2.0 een tijd lang moeten laten voor wat het is. Momenteel ben ik me er weer in aan het verdiepen en loop gelijk weer tegen hetzelfde probleem aan. Destijds was de response niet overweldigend, dus ik hoop dat er nu iemand is die er wat uitgebreider op in kan gaan.

Laten we even een heel simpel voorbeeld nemen. Als ik in VS 2003 / ASP.NET 1.1 een dropdownlist wilde vullen met data, deed ik dat over het algemeen als volgt:

Ik maakte een SqlCommand op basis van een stored procedure. VS 2003 maakt netjes voor mij de SqlCommand met bijbehorende parameters. Deze command werd onderaan de pagina gezet (zie screenshot in eerdere post). Vervolgens vulde ik de dropdownlist als volgt:

code:

Me.conn.Open()
Dim dr As SqlDataReader = Me.cmdGebruikers.ExecuteReader
    While dr.Read
            Me.ddlGebruikerSelect.Items.Add(New ListItem(dr.Item("gebruikersNaam"), dr.Item("gebruikerID")))
    End While
Me.conn.Close()

Ik heb altijd 'geleerd' dat deze methode de voorkeur had boven het gebruik van een dataset.

Wil ik dit nu doen in VS 2008 en met ASP.NET 2.0 dan moet ik - volgens de boeken die ik heb - een SqlDataSource aanmaken en deze binden aan de dropdownlist. Hier heb ik de volgende opmerkingen / vragen over:

1) Voor zover ik het kan zien is de SqlDataSource een DataSet of een DataReader. Althans, DataSourceMode kan worden ingesteld op DataSet (standaard) of DataReader. Ik heb destijds geleerd dat een dataset redelijk 'zwaar' is en je het gebruik ervan zoveel mogelijk moet vermijden; zelf gebruik ik datasets bijv. alleen voor het vullen van datagrids. Het voelt daarom verkeerd om voor elk wissewasje zo'n SqlDataSource aan te maken. Ik heb het gevoel dat dit een te zwaar object is voor wat ik wil bereiken (bijv. een dropdownlist vullen). Is dit gevoel gerechtvaardigd? Zijn er alternatieven?

2) Deze SqlDataSource wordt in de HTML geplaatst waardoor de layout van een pagina in design mode wordt verpest. Is hier een alternatief voor? Hoe gaan andere mensen hier mee om? Ik kan me namelijk goed voorstellen dat het erg vervelend is om tig van dergelijke datasource objecten op je pagina te hebben.

[André]

Move naar Programming

[D-Raven]

Je hebt helemaal gelijk als je zegt dat het gebruik van de SqlDataSource onhandig is.Het feit dat je ongelofelijke klutter in je code krijgt (voor elk databound element een eigen sqldatasource). Is voor mij een big no no.

Ik gebruik het persoonlijk puur voor prototyping. Snel ff iets in elkaar gooien om voor een proof of concept of zoiets dergelijks.
Een alternatief is om je eigen DAL te implementeren. Waarin methodes zitten die reflecteren welke data je wilt ophalen.

Je kunt bijvoorbeeld een lijst van objecten aan de datasource van je dropdown list toekennen, en voila.

Er zijn verschillende opties om je DAL vorm te geven. Je kunt NHibernate/ActiveRecord gebruiken, misschien wil je met iets meer licht gewicht beginnen en zelf iets maken. Whatever je gaat doen, het alternatief is dat je niet de designer met de sqldatasource gebruikt maar zelf iets maakt.

Hoe dat dan precies vorm gegeven wordt is aan jou zelf

[mOrPhie]

Met Deathraven. Voor iets meer flexibiliteit zou je de ObjectDataSource kunnen gebruiken als portal tot je DAL of BL (afhankelijk van hoeveel lagen je wilt gebruiken). Het voordeel van het gebruik van een ObjectDataSource is dat je redelijk gemakkelijk kunt overstappen van een repeater naar een datalist bijvoorbeeld. Je hebt dan alleen wel hetzelfde als met de SqlDataSource dat het aantal kan groeien. Sja, dat is ook maar net hoe je werkt. Ikzelf kom haast nooit in design-mode en vind het dus niet erg als er een datasource meer of minder op m'n webform staat.

[Verwijderd]

Je zou eens kunnen kijken naar MyGeneration. Hiermee kun je je eigen classes en sprocs laten generen aan de hand van je database.

Zodra je die class hebt gebruik je een objectdatasource om er tegen aan te kletsen.

Als je een goed template hebt gemaakt is het maken van je class een kwestie van 1 druk op de knop.

Simpel en het kost geen tijd meer.

[VanRoyal]

Bedankt voor de tips, zodra ik weer wat tijd heb (zucht) ga ik er weer induiken.

Rest nog steeds de vraag: Waarom heeft MS besloten om sqlcommands e.d. uit de designer te halen? Ze zijn in de code nog steeds te gebruiken en voor zover ik kan zien moet je dat nog veelvuldig doen. Ik kan me dan niet voorstellen dat er ook maar iemand is die het leuk vindt om ze handmatig aan te maken. Maarja, misschien ben ik wel gewoon te lui (geworden)