Warum ist das ASP.NET-Profil so schrecklich gestaltet?

Question

Im aktuellen Projekt, an dem ich gerade arbeite, verwenden wir das asp.NET-Profil, um Informationen über Benutzer zu speichern, z. B. ihre Beteiligung an einer Mailing-Liste.

Jetzt, um eine Liste aller Benutzer in der Mailing-Liste zu erhalten, kann ich nicht einfach eine Datenbankabfrage tun, wie die ASP.NET-Profiltabelle ist einfach gesagt, schrecklich.

Für diejenigen, die nicht wissen, hat die Profiltabelle zwei Hauptsäulen, die ‚Schlüssel‘ Spalte und ‚Werte‘ Spalte, und sie sind so organisiert:

Keys: Key1: datatype: start : endIndex: Schlüssel2: dataType. . usw.

Werte: value1value2value3 ...

Dies ziemlich unmöglich ist SQL zur Abfrage verwenden, so dass die einzige Option, um Benutzer zu finden, die eine bestimmte Eigenschaft hat, ist eine Liste aller Benutzer zu laden und Schleife durch es hindurch.

In einer Site mit über 150k Mitgliedern ist dies verständlicherweise sehr langsam!

Gibt es bestimmte Gründe, warum das Profil so entworfen wurde, oder ist es nur eine schreckliche Art, dynamisch generierte Daten zu erstellen?

Answer 1

Der springende Punkt des Provider-Modells ist, dass es die Datenquelle abstrahiert. Die Idee ist, dass Sie als Entwickler nicht wissen müssen, wie die Daten gespeichert sind oder in welchem ​​Format - Sie haben nur eine Reihe von Methoden, um darauf zuzugreifen. Dies bedeutet, dass Sie Anbieter wechseln können, ohne eine einzelne Codezeile zu ändern. Es bedeutet auch, dass Sie speziell nicht versuchen und Daten direkt von der Datenquelle zugreifen (z. B. direkt in die Datenbank gehen) durch Umgehen der Provider-Methoden - das schlägt den ganzen Punkt. Der Standard ASP.NET Profilprovider ist tatsächlich sehr sehr leistungsfähig, da er nicht nur einfache Werttypen (Strings, Ints etc.) speichern kann, sondern auch komplexe Objekte und ganze Sammlungen in einem einzigen Feld speichern kann. Versuchen Sie das in einer relationalen Datenbank! Der Nachteil dieses Generic-Ism ist jedoch, dass es auf Kosten der Effizienz geht. Wenn Sie also ein bestimmtes Bedürfnis haben, sollten Sie Ihren eigenen Anbieter implementieren. Siehe zum Beispiel SearchableSqlProfileProvider - The Searchable SQL Profile Provider.

Natürlich ist Ihre dritte Option, einfach nicht den Profilanbieter zu verwenden - niemand zwingt Sie dazu!Sie könnten Ihre eigenen Klassen/Datenbanken vollständig implementieren, wie Sie es in anderen Frameworks hätten tun müssen.

Answer 2

Ich habe verschiedene benutzerdefinierte Anbieter (Mitgliedschaft/Sitemap/Rollen usw.) implementiert und habe nicht wirklich den ASP.NET-Profilanbieter angeschaut, nachdem ich so etwas gesehen habe (Name/Wert-Paare oder XML-Daten). Ich bin mir nicht sicher, aber ich denke, das Profil wird primär für Benutzereinstellungen/Einstellungen erstellt, wo die Einstellungen nur für einen bestimmten Benutzer benötigt werden. Ich glaube nicht, dass das Profil für Benutzer "Daten" gedacht ist, die abgefragt werden können.

Hinweis: Dies ist eine Annahme basierend auf dem, was ich denke ich weiß, bitte kommentieren Sie dies sonst.

Answer 3

Ich stimme zu, dass es eine ziemlich schlechte Möglichkeit ist, Profildaten zu speichern, aber ich vermute, der Anwendungsfall bestand nur darin, die Profildaten für einen Benutzer mit einer einzelnen Abfrage zu erhalten, aber so zu erweitern, dass sie bearbeitet werden können Anzahl der verschiedenen Profileigenschaften. Wenn Sie es nicht mögen, können Sie immer Ihre eigene, benutzerdefinierte profile provider schreiben, die jeden Wert in eine eigene Spalte trennt. Nachdem ich verschiedene Mitgliedschafts- und Rollenanbieter implementiert habe, glaube ich nicht, dass dies eine zu komplizierte Aufgabe wäre. Die Anzahl der Methoden sieht nicht zu groß aus.