Hello,
ASP.NET nutzt(e) dieses Konzept seit 2002. Es existiert also schon seit langem genug Erfahrung damit.
Das ist kein Grund. Das kommt von Microsoft, soweit ich mich erinnere und dort wird bekanntlich nie etwas fertig entwickelt, bevor es verbreitet wird. ;-P
Ja ach! Wenn eine Antwort vom Server verloren geht, sind Daten verloren! Mach Sachen! 😉
Ich nehme jetzt einfach mal an, dass Du mir auf humorvolle Weise sagen wolltest, dass Dich das nicht weiter interessiert?
Es war wohl eher damit gemeint, dass man sowieso damit rechnen muss, dass mal was verloren gehen kann, und man generell geeignete Maßnahmen bei Verlust vorsehen muss. Auch ein Session-Cookie kann abhandenkommen. In jedem Fall muss also der Client dem Server Daten bereitstellen, damit das System ordnungsgemäß funktioniert. Ob das nur ein Cookie ist, oder ob es mehr Daten sind, spielt dann auch keine Rolle mehr.
Das ist nicht genau genug betrachtet. Es kommt immer darauf an, auch welcher Seite (Client oder Server) die relevanten Daten gehalten werden sollen. Diese Seite sollte auch immer den letzten Stand kennen (gespeichert haben). Da viele Daten im Webumfeld erst einmal transient sind, wäre es ein extremer Overhead, dies nicht mit den üblichen (datensicheren) Sessionkonzepten zu lösen. Spätetens beim Löschen der Sessiondatei ist das Problem mit dem Datenmüll beseitigt. Anderenfalls wird das Müllwegräumen extrem aufwändig.
Was nicht committed ist, muss noch nicht persistent gespeichert werden. Um da zu früh abgespeichete unfertige Ziwschenlösungen später wieder zu entfernen, muss man sonst zusätzliche Maßnahmen vorsehen. Das kostet Entwicklungszeit, Ressourcen und Performance.
Liebe Grüße
Tom S.
Es gibt nichts Gutes, außer man tut es
Andersdenkende waren noch nie beliebt, aber meistens diejenigen, die die Freiheit vorangebracht haben.