Entity Framework en ASP.Net webforms

[Lethalis]

Beste tweakers,

In navolging van mijn andere thread:
.Net Data Access, wat is nou het beste?

Heb ik een wat specifiekere vraag, in dit geval over het Entity Framework.

Gegeven is een hele eenvoudige situatie:
- Een webpagina waarop je klant gegevens kunt wijzigen

Als je nu volgens het principe werkt dat een ObjectContext maar kort dient te bestaan, dan ben ik geneigd om het volgende te doen:
- Een CustomerManager class bouwen die dmv FindById de juiste Customer teruggeeft
- De class krijgt in de constructor de ObjectContext mee

Om customer 1 op te halen kan ik dus de volgende code schrijven:

code:

Using context As New TestEntities()
  Dim custManager As New CustomerManager(context)
  Dim cust As Customer = custManager.GetById(1)
End Using

Hieraan zou ik dan mijn textboxes, etc binden (txtCustomerName.Text = cust.Name, etc).

Vervolgens wijzig je de inhoud van de textbox en druk je op Save. Je krijgt dan een postback (of callback bij het gebruik van UpdatePanel, maar dit laten voor het gemak even buiten beschouwing).

Op het moment dat je in het btnSave_Click event komt, wil je graag de nieuwe gegevens bewaren.

Wat is nu wijsheid?

1. ObjectContext en opgevraagde entities ergens bewaren? Zodat je change tracking hebt.
2. Iets proberen met lazy loading, om een Customer object te krijgen en de velden te wijzigen, zodat je weer een update kunt doen.
3. ???

I'm confused. Dit is een erg simpele (en verzonnen) toepassing, maar ik wil voorkomen dat ik de klant een 2e keer moet ophalen voordat ik een update doe.

Ik kan mij niet voorstellen dat dit moeilijk zou moeten zijn, dus ik zie vast iets over het hoofd. Tevens heb ik gezocht naar voorbeelden op internet, maar weinig tot niks gevonden.

Ook wil ik geen gebruik maken van EntityDataSource, maar zelf controle hebben over welke controls ik populate en wanneer.

Wie helpt?

[Razr]

Ik vraag me twee dingen af, namelijk:

1. Waarom zelf een 'CustomerManager' voor CRUD methoden voor je Customer class schrijven als je voor deze functionaliteit prima een O/R mapper als CoolStorage.NET kan gebruiken. Is erg simpel in gebruik.
2. Waarom wil je niet 2x het klant object ophalen? Ben je bang dat dit bijv. performance problemen gaat geven? Je DBMS kan aardig wat requests afhandelen voordat jij hier last van gaat krijgen En anders zou je misschien het object in je ViewState / Session kunnen opslaan mocht je dit perse willen.

[Lethalis]

Razr schreef op donderdag 12 maart 2009 @ 21:18:
Ik vraag me twee dingen af, namelijk:

1. Waarom zelf een 'CustomerManager' voor CRUD methoden voor je Customer class schrijven als je voor deze functionaliteit prima een O/R mapper als CoolStorage.NET kan gebruiken. Is erg simpel in gebruik.
2. Waarom wil je niet 2x het klant object ophalen? Ben je bang dat dit bijv. performance problemen gaat geven? Je DBMS kan aardig wat requests afhandelen voordat jij hier last van gaat krijgen En anders zou je misschien het object in je ViewState / Session kunnen opslaan mocht je dit perse willen.

1. Ik gebruik al het Entity Framework in dit voorbeeld, de CustomerManager class is gewoon een methode om je Linq queries netjes bij elkaar te houden (repository pattern).

2. Het gaat om het principe. Ik werk soms aan web applicaties waar gemiddeld tussen 500 en 1000 users per minuut op dezelfde pagina's zitten. Dan is het niet prettig als een SQL Server met 16GB RAM hebt draaien die continu op 40% processor belasting staat, als je dan ook nog eens steeds het object opnieuw gaat ophalen.

Oftewel: dit moet beter kunnen!

Ik ben gewend om gewoon met stored procedures te werken en veel te doen met DataTable's. Maar sinds kort ben ik erg geinteresseerd geraakt in de verschillende o/r mappers (Linq2sql, Entity Framework, NHibernate, LLBLGen), en onderzoek ik de praktische toepasbaarheid ervan.

1 van de criteria is uiteraard performance.

[Cloud]

Dan nog zou je, zoals Razr al zegt, in dit geval je Customer in de ViewState of Session kunnen plaatsen. Zo is hij simpel te gebruiken in de volgende request. Dat is de meest eenvoudige aanpak. Je zou ook bijvoorbeeld alleen het UserId op kunnen slaan en alleen de gewijzigde velden naar je DBMS door kunnen sturen. Lazy saving, dus eigenlijk. Zelf zou ik gewoon gaan voor het opslaan van het object in je ViewState.

[Lethalis]

Cloud schreef op vrijdag 13 maart 2009 @ 09:08:
Dan nog zou je, zoals Razr al zegt, in dit geval je Customer in de ViewState of Session kunnen plaatsen. Zo is hij simpel te gebruiken in de volgende request. Dat is de meest eenvoudige aanpak. Je zou ook bijvoorbeeld alleen het UserId op kunnen slaan en alleen de gewijzigde velden naar je DBMS door kunnen sturen. Lazy saving, dus eigenlijk. Zelf zou ik gewoon gaan voor het opslaan van het object in je ViewState.

Dan blijft eigenlijk de vraag hoe 'heavy' de ObjectContext van het Entity Framework is? Want ik krijg immers dan 500 tot 1000 instanties ervan.

Ik heb gelezen dat de context van Linq2sql erg lightweight is, maar kan niet echt iets vinden over die in het EF.

[ Voor 3% gewijzigd door Lethalis op 13-03-2009 09:48 ]

[Cloud]

Lethalis schreef op vrijdag 13 maart 2009 @ 09:48:
Dan blijft eigenlijk de vraag hoe 'heavy' de ObjectContext van het Entity Framework is? Want ik krijg immers dan 500 tot 1000 instanties ervan.

Daarom is de ViewState ook mogelijk de juiste keuze. De ObjectContext wordt dan opgeslagen in de browser van de gebruiker. Hoeveel instanties je dan ervan hebt is irrelevant omdat ze niet op jouw server opgeslagen worden.

Of begrijp ik je verkeerd en kijkt één browser ook al naar 500 tot 1000 instanties van je Customer? We hebben het hier nog steeds over het wijzigen van klantgegevens, toch?

[Lethalis]

Cloud schreef op vrijdag 13 maart 2009 @ 10:03:
[...]

Daarom is de ViewState ook mogelijk de juiste keuze. De ObjectContext wordt dan opgeslagen in de browser van de gebruiker. Hoeveel instanties je dan ervan hebt is irrelevant omdat ze niet op jouw server opgeslagen worden.

Misschien moet je nog even kijken wat ViewState zoal doet

Het probleem van de viewstate is dat je nogal wat extra traffic krijgt van en naar je site, omdat de viewstate bij elke request mee wordt gestuurd en iets is wat je ten allen tijde wil vermijden bij drukke websites.

[Cloud]

Lethalis schreef op vrijdag 13 maart 2009 @ 17:02:
Misschien moet je nog even kijken wat ViewState zoal doet

Ik ben bekend met de ViewState, dank je wel.

Het probleem van de viewstate is dat je nogal wat extra traffic krijgt van en naar je site, omdat de viewstate bij elke request mee wordt gestuurd en iets is wat je ten allen tijde wil vermijden bij drukke websites.

Tja óf je bewaart 500 tot 1000 instanties in je server geheugen (en dus je geheugen gebruik neemt flink toe) óf je bewaart ze in de browser van de bezoeker en hebt wat meer dataverkeer. Die afweging zul je moeten maken op het moment dat het nodig is; zoiets is niet bij voorbaat al te zeggen zonder de details van de applicatie al te weten. Hoe groot is je Customer object? Dat is ook een vraag die nogal van belang is bij dit alles. Als je het in je ViewState opslaat, hoeveel groter wordt die dan?

Op deze manier is dit echt praten in het luchtledige want er valt geen één, altijd correcte, oplossing te geven. Teveel onbekenden. Als je dit daadwerkelijk tegenkomt, ga dan testen. Test meerdere oplossingen tot je de meest geschikte voor die situatie overhoudt.

[Lethalis]

Cloud schreef op vrijdag 13 maart 2009 @ 20:08:
1) Ik ben bekend met de ViewState, dank je wel.

2) Tja óf je bewaart 500 tot 1000 instanties in je server geheugen (en dus je geheugen gebruik neemt flink toe) óf je bewaart ze in de browser van de bezoeker en hebt wat meer dataverkeer. Die afweging zul je moeten maken op het moment dat het nodig is; zoiets is niet bij voorbaat al te zeggen zonder de details van de applicatie al te weten. Hoe groot is je Customer object? Dat is ook een vraag die nogal van belang is bij dit alles. Als je het in je ViewState opslaat, hoeveel groter wordt die dan?

Op deze manier is dit echt praten in het luchtledige want er valt geen één, altijd correcte, oplossing te geven. Teveel onbekenden. Als je dit daadwerkelijk tegenkomt, ga dan testen. Test meerdere oplossingen tot je de meest geschikte voor die situatie overhoudt.

1) Dat kwam er misschien wat lullig uit, mijn excuses.

2) Het punt is echter dat ik op dit moment geen van beide heb met stored procedures.

Ik heb het trouwens gemeten nu, en het valt soort van mee:

Mijn dev webserver is met 33 MB gegroeid na het aanmaken van 1000 TestEntities (objectcontext).. nu zaten er maar 9 tabellen in mijn entity model. Maar als dit alles is, is het goed te doen.

En met 477MB bij 10000

Ik zal de testcase eens uitbreiden.

PS:
Server geheugen is doorgaans goedkoper dan bandbreedte.. dus sessionstate lijkt dan logischer.

[ Voor 46% gewijzigd door Lethalis op 14-03-2009 09:59 ]

[Cloud]

Kijk nu praten we ergens over Bij dit soort waarden is inderdaad de SessionState de logische keuze. 477 mb bij 10.000 stuks is echt heel erg goed te doen, een beetje webserver zal daar geen problemen mee hebben. Dan is het logisch om je viewstate (ofwel requests) zo klein mogelijk te houden (of liever VS uit te schakelen).