OK, więc po pierwsze, zanim ktoś spróbuje ustalić, że jest to" duplikat " pytanie; przejrzałem większość postów na tak dotyczące podobnych pytań, ale nawet w połączeniu z tym wszystkim, co zostało powiedziane, nadal jestem nieco w dylemacie co do ostatecznego, a może powinienem powiedzieć jednomyślne porozumienie w tej sprawie.

Mogę jednak powiedzieć ,że mam (na podstawie postów) jednoznacznie ustalone, że odpowiedź opiera się na zakresie wymogu. Ale nawet z biorąc to pod uwagę, opinie wydają mi się zbyt zróżnicowane, aby podjąć decyzję, jak powinienem sobie z tym poradzić.

Moim natychmiastowym wymogiem jest to, że muszę utrzymywać zmienne dane z 1 kontrolera w wielu widokach. Dokładniej mówiąc, mam kontroler i odpowiedni widok, który obsługuje liczbę pozycji koszyka i chciałbym zachować te dane w wielu widokach. Myślę, że widok _layout jest najbardziej logicznym wyborem.

Teraz udało mi się zrealizowano to zadanie, przypisując wartość do zmiennej sesji, która jest pobierana z widoku my _layout; więc nawet wtedy, gdy użytkownik miał nawigować w dowolnym miejscu w witrynie, liczba pozycji w Koszyku będzie utrzymywać się aż do opuszczenia witryny lub zakończenia realizacji zakupu; w takim przypadku zmienna zostanie wyczyszczona w kodzie.

Posty, które czytałem, wydawały się stronnicze, albo trzymając się z dala od zmiennych sesji na rzecz plików cookie i przechowywania danych w bazie danych; lub stwierdzając, że dla zamierzonego celu, dla którego proponuję ich używać, zmienne sesji są całkowicie w porządku w użyciu.

Inna rzecz, którą czytałem sugeruje, że zmienne sesji mogą potencjalnie utrudniać ogólną wydajność, jeśli jest duży ruch na stronie, ponieważ informacje są przechowywane na serwerze.

Osobiście nie mogę uzasadnić przechowywania tego typu informacji w bazie danych, a następnie uderzania w bazę danych, ponieważ wyobrażam sobie, że może to również wpłynąć na wydajność witryny i wydaje się nieco overkill do przechowywania danych tymczasowych. TempData, ViewData i ViewBag nie działają w utrzymywaniu danych, więc nie są logicznym wyborem dla wymogu IMO.

Jeśli istnieje inna dobrze dopasowana alternatywa dla zmiennej Sesyjnej (która działa dla mnie), Chciałbym wiedzieć, co to jest.

2 posty, które wydają się sprzeczne w celu zapewnienia najlepszych rekomendacji, pozostawiają mnie trochę zdezorientowanym.

Wady: czy jest dobrą praktyką unikanie używania stanu sesji w ASP.NET MVC? Jeśli tak, to dlaczego i jak?

Plusy: nadal ok, aby używać zmiennych sesji w ASP.NET mvc, czy jest lepsza alternatywa dla niektórych rzeczy (np. wózek)

Wydaje się, że to pytanie (choć przedstawione w wielu różnych odmianach) nie ma ostatecznej odpowiedzi, którą mogę stwierdzić.

Jeśli istnieje bardziej preferowany sposób, aby to osiągnąć bez przesady, to jest to odpowiedź, której szukam.

Czytałem gdzieś o stosowaniu filtrów MVC w tandemie z Global.sekcja startowa aplikacji ascx również, ale nie wydaje się to odpowiednie dla zmiennych ustawionych na poziomie kontrolera tak samo jak być może zmienne statyczne.

Może ktoś może zgnieść (z braku lepszego słowa) wiele różnorodnych opinii na ten temat i może dać bardziej ostateczną odpowiedź na pytanie? Jestem pewien, że różne opinie mają swoje miejsce i nie próbuję ich zdyskredytować. Ale mając ostateczną i ewentualnie jednomyślną odpowiedź byłoby lepiej; wtedy ja może sortować inne posty, aby określić, co jest najlepsze dla mojej aplikacji.

Oczywiście, jeśli to pytanie nie ma ostatecznej odpowiedzi; po prostu mi to powiedz, a postaram się uzyskać własną odpowiedź z innych postów.

Thanks

===========================================================

ZAKTUALIZOWANA ODPOWIEDŹ NA UDZIELONE ODPOWIEDZI

Buforowanie i pliki cookie wydają się być ogólną preferencją od odpowiedzi, jednak zauważyłem również stwierdzenie, że buforowanie nie jest to idealny kandydat do użycia na wielu serwerach internetowych, ponieważ synchronizacja może być potencjalnym problemem.

Przypisując Timowi, stwierdzono, że przechowywanie danych jest zoptymalizowane, a użytkownicy mają możliwość powrotu w późniejszym czasie i kontynuowania tam, gdzie przerwali.

To doskonały punkt, ale zachowując przewidywania na prawdopodobieństwach; jego prawdopodobne rozsądne biorąc pod uwagę, że niektórzy użytkownicy mogą nie wrócić pozostawiając nienaturalne dane w bazie danych.

Więc utrzymanie DB optymalizacji i clean (co "dla mnie" jest równie istotne) wymagałoby realizacji zadania konserwacyjnego, aby automatycznie wygasnąć te zapisy w oparciu o ustalony próg czasu, aby uwzględnić te okoliczności. Chociaż zadanie konserwacyjne nie jest niezaprzeczalną opcją, nadal uważam, że dodaje to nieco więcej pracy do zadania po prostu w celu służenia jako tymczasowe przechowywanie.

Niemniej jednak, szanuję rekomendację Tima i uważam, że zasługuje ona na zasługi w przeciwdziałaniu mojej początkowej opinia w pewnym stopniu; że baza danych nie wydaje się być realną opcją do przechowywania tymczasowych danych; więc myślę, że kompromisem byłoby przechowywanie danych w bazie danych (biorąc pod uwagę scenariusz koszyka lub podobne) być może po kasie. W ten sposób, jak wcześniej stwierdziłeś, dane mogą być stale śledzone podczas kolejnych wizyt, dzięki czemu masz zapis transakcji. Ale co ważniejsze, dane o tych transakcjach mają realne znaczenie, aby utrzymać się na baza danych.

Stwierdzono również, że chociaż sesja jest szybsza niż Baza Danych; ale pomimo tego, że ma swoje zastrzeżenia, które mogą być w pewnym stopniu złagodzone przez inne mechanizmy, takie jak wykorzystanie atrybutu SessionStateBehavior, służy tylko jako jeden przykład.

Ale... Myślę, że Erik pojechał do domu z efektem Dunninga-Krugera. Chociaż z treści i wyjaśnień proponowanych odpowiedzi udzielonych tutaj; poważnie wątpię w wiedzę żadnej z osób kto odpowiedział, jest wątpliwy. Niemniej jednak, mam tendencję do zgadzania się co do faktu, że uzyskanie jednomyślnej opinii może być nieco wyższe niż rozsądne oczekiwania z mojej strony.

To, czego szukałem dokładniej, to ogólny konsensus w sprawie techniki, która wygodnie zmieściłaby się w wielu różnych scenariuszach. Innymi słowy, coś, co pasuje nie tylko do mojego konkretnego scenariusza, ale także zapewni element skalowalności dla większych środowisk z potencjalnie większy ruch. W ten sposób zmiana w programowaniu byłaby albo złagodzona całkowicie, albo w najlepszym razie Minimalna.

==================================================

Podsumowanie na podstawie opinii:

1. Zmienne sesyjne wydają się uwzględniać mniejsze scenariusze przypadków i w stosownych przypadkach, ale mają pewne potencjalne obawy dotyczące trwałości, wśród innych znaczących rozbieżności, jak stwierdził bardzo dokładnie Erik. Więc ta opcja oczywiście nie zmieści się skalowalny model.

2. Buforowanie jest lepsze niż zmienne sesji, ale ponownie nie jest "najlepszą" opcją skalowalną ze względu między innymi na potencjalne złożoności synchronizacji w środowiskach farmy serwerów WWW, jak wcześniej wspomniano. Ale jednak opcja.

3. Przechowywanie danych w bazie danych jest skalowalne, ale w celu tymczasowego przechowywania danych nie jest prawdopodobnie najbardziej elegancką opcją z punktu widzenia bazy danych, ponieważ wymagałaby okresowe sprzątanie. Osobiście, posiadanie silnych podstaw w koncepcjach bazodanowych na początku mojej kariery prawdopodobnie nie będzie to czymś, z czym wielu programistów prawdopodobnie się zgodzi; ale używanie bazy danych w tym celu może wystarczyć do tworzenia stron internetowych z perspektywy programistów; jednak z perspektywy rozwoju DAL i DB to (dla mnie) ma potencjał, aby zlecić dodatkowe zadanie DB, aby wymusić wydajny backend.

4. Ciasteczka wydają się być miłe opcja posiadająca połączone "pożądane" elementy zmiennych sesji i buforowania.

==================================================

Podsumowanie

W oparciu o odpowiedzi; myślę, że pliki cookie i buforowanie wydają się być ogólnie dobrze zaokrąglone propozycje najlepszych praktyk w połączeniu z przechowywaniem bazy danych, gdy po fakcie wymagana jest ciągła trwałość; jako potencjalnie dobre kandydatury do skalowalności prezentowanych.

The ostateczny wybór między 2 wydaje się być oparty na ilości i rodzaju danych wymagających przechowywania (np. wrażliwe vs niewrażliwe i czy istnieje obawa, że klient może zmienić dane na ich końcu); oprócz szczególnych rozważań dotyczących plików cookie w tym, że mogą być one wyłączone przez klientów.

Oczywiście, nie ma jednego uniwersalnego rozwiązania, jak wyraźnie wskazano i wyciągnięto z udzielonych odpowiedzi, ale jeśli chodzi o skalowalność; mogę się mylić ale wydaje się, że są to najlepsze dostępne opcje.

Ponieważ wszystkie odpowiedzi są dobre; zamierzam uznać wszystkie posty za przydatne i zaakceptuję odpowiedź Erika jako dobrze zaokrąglone ogólne skalowalne rozwiązanie. Chciałbym móc wybrać więcej niż jedną akceptowaną odpowiedź, ponieważ uważam, że odpowiedź Tima była również bardzo dobrze ułożona i zwięzła.

Odpowiedź Gupty też była dobra, ale chciałem więcej rozwinięcia proponowanej odpowiedzi, a nie powtórzenia poprzednich postów.

Dzięki Chłopaki!