Re: Performance: SQL-Server mit ASP-NET oder WinForms

Peter,

danke für die kritischen Worte.
Sorry, ich hatte leider WebForms anstatt WinForms geschrieben.
Von WinForms habe ich noch keine Ahnung.

In einem DataGrid kann man doch 9000 Sätze ( 1 MByte an Daten)
mit incrementeller Suche in allen Spalten (4 Datenfelder) und Sortieren nach
allen
Spalten blitzschnell auf den gewünschten Satz positionieren?
Das ist doch nicht zu vergleichen mit Schreibmaschinenseiten, die ich
wirklich
durchlesen muß!
Schnelle Sortiermöglichkeiten mit incrementeller Suche jeweils nach/in allen
Datenspalten, sind doch das a+o bei großen Listen.

Ich verstehe Deine Aufregung nicht. Mit den 9000 Sätzen, das muss ich
vermutlich runterbrechen.
Aber alleine das erneute Laden einer Seite wenn ich zB in einer ComboBox
einen Eintrag wechsele und damit in einer 2. Combobox eine neue Auswahlliste
angezeigt werden muss, ist doch schon gelinde gesagt "unschön".

Meine Hauptfrage ist einfach:
Sind WinForms nicht grundsätzlich schneller (wenn das Design stimmt) als
WebForms
wenn größere Datenmengen zur Anzeige gebracht werden müssen?


Calle

"Peter Fleischer" <peter.fleischer_nospam_@xxxxxx> schrieb im Newsbeitrag
news:%23vdsM9oPFHA.2932@xxxxxxxxxxxxxxxxxxxxxxx
> Calle Manthey wrote:
> ...
> > vielen Dank für Deine ausführliche Antwort.
> >> lediglich 130 kByte Information, was für eine 2 MB-Leitung nun keine
> >> Belastung darstellt.
> >
> > Ich habe nachgerechnet, es sind 1 MByte an Daten.
>
> Calle,
> das sind 500 Schreibmaschine-Seiten. Wie lange denkst du, dass ein
Anbwender
> diese durchliest? Auch wenn er nur blättert, dauert das länger als
> mehrmalige Übertragungen.
>
> ...
> > Nach jeder Auswahl müssen per Postback (asp.net) die Daten gesucht und
> > geholt werden und
> > die Seite muss im Browser neu angezeigt werden. Alleine der Aufbau
> > der Seite lässt ein
> > schnelles Arbeiten im Web nicht zu.
>
> Warum nicht? Wenn die Seiten im kByte-bereich bleiben, dann geht das schon
> recht schnelle, jedenfalls schneller als ein Anwedner den Inhalt lesen
kann.
>
> > Ich habe noch keine Erfahrung mit WebForms:
> > der permanente Seitenaufbau bei asp.net (der bei allen Änderungen auf
> > der Seite, die nicht per JavaScript erledigt werden können, notwendig
> > ist,) entfällt ja wohl dort.
>
> Du solltest dich mal mit den Grundlagen beschäftigen, da du vermutlich
> Rendern mit Übertragen und Darstellen im Client verwechselst.
>
> > Dies scheint mir eine Voraussetzung für schnelles Arbeiten zu sein.
>
> Schnlees Arbeiten ist vor allem Design so, dass der Anwender auch schnell
> versteht, was zu machen ist. 500 Schreibmaschinen-Seiten lesen dauert
> garantiert lange.
>
> > Wahrscheinlich ist auch das Disconnected Konzept von ado.net schuld an
> > Performance-Problemen.
>
> Wo hast du ein Performance-Problem? Beim Lesen von 500
> Schreibmaschinen-Seiten. Dan wechsle den Anwedner :-)
>
> > OT: Selige Clipperzeiten - zumindest in dieser Hinsich. Da spielte es
> > (fast) keine Rolle wie gross die
> > DBF war, die im T-Browse angezeigt wurde.
>
> Und ohne PC hat man 0 Stunden für die Arbeit mit dem PC verbraucht. Das
> waren noch Zeiten :-)
>
> > Gibt es auch ein Connected Scenario?
>
> Meinst du jetzt Windows- oder Webanwendungen?
>
> > Der DataReader ist ja auch nicht
> > wirklich immer connected, denn die
> > Daten müssen ja - um sie zu bearbeiten - in ein Control kopiert
> > werden (und stehen deshalb disconnected im
> > Speicher zur Verfügung).
>
> Man kann auch jeden Tastenanschlag sofort in die Datenbank schreiben.
Damit
> ist der Anwender "connected". Ob das aber sinnvoll ist, hängt von der
> Aufgabenstellung ab. Kein Anwender benötigt Daten im Millisekundenbereich.
>
> > Zugespitzt: kann es aus Performance-Gründen sinnvoll sein, in jedem
> > beteiligten LAN einen SQL-Server
> > als Zwischenspeicher zu installieren und dann daraus Nachts per Batch
> > einen zentralen SQL-Server zu füttern,
> > mit all den Problemen die dann aus den unterschiedlichen Datenständen
> > entstehen?
>
> Du kannst ja mal beim öffentlichen Dienst in Großstädten anfragen
> (vielleicht nicht in allen). Die machen das so und haben damit eine gute
> Auslastung vieler Mitarbeiter:-) Das hat aber weniger mit Performance als
> mit deren Vorstellungen von Sicherheit zu tun.
>
> Wenn du schon den Aufwand zur Installation vieler SQL-Server treiben
willst,
> dann wäre es vielleicht besser, den Aufwand in die Durchlassfähigkeit der
> Netze und der Leistungsfähigkeit der Server zu stecken.
>
> Peter
>


.

Relevant Pages

  • Re: Webforms vs. Winforms decision
    ... Web development takes much more time than windows developer. ... Make sure it is available for the platform (WinForms of WebForms) you ... some of the same components but the two applications are separate. ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Re: Webforms vs. Winforms decision
    ... deploy using Webforms or Winforms and I need advice from someone who is ... looking back we should have gone the Winforms route... ... need to know about HTML, CSS, JavaScript & IIS. ... - Some parts of our app demand a lot of data-entry. ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Re: Winforms v webforms?
    ... WinForms are overall much easier to develop, and faster to use, but WebForms ... This is an executable that can automatically update itself ... I never worded what I wanted to know properly and getting quick advice ...
    (microsoft.public.dotnet.general)
  • Re: Webforms vs. Winforms Decision
    ... If you use Winforms, you begin having a deployment problem. ... webforms and the asp.net web controls that come with asp.net, ... some of the same components but the two applications are separate. ...
    (microsoft.public.dotnet.general)
  • Re: Eventergebnisse in WebForm anzeigen
    ... dass WebForms nicht wie WindowsForms funktionieren. ... gestartet, wenn der Client die Seite anfragt, bzw. einen Postback erzeugt. ... einzufärben, oder du setzt ein Meta-Refresh in den Head-Bereich deiner ...
    (microsoft.public.de.german.entwickler.dotnet.asp)