Przechowywanie informacji pomiędzy widokami

0

Czołem koledzy programiści!

W swojej aplikacji (ASP.NET Core MVC) konstruuję tworzenie zamówienia. Chciałbym przeprowadzić użytkownika przez kilka różnych widoków, gdzie ustawi on parametry zamówienia i finalnie nowy rekord powędruje do bazy danych.
Moim problemem jest przechowywanie wprowadzanych danych, tak aby ostatecznie wszystkie trafiły one do rekordu bazy danych. Dotychczas korzystałem z przechowywania danych w sesji, lecz, dużo czytając tutaj na forum, wysnuwam wniosek, iż jest to słabe rozwiązanie.

Jak najlepiej to rozwiązać?

1

No np. dane z etapu 1 przesyłasz na kontroler, ten je dodaje do viewmodelu etapu 2, widok etapu 2 przechowuje te dane w hidden fieldach, a potem odsyła do kontrolera, ten dodaje dane z etapu 1 oraz 2 do viewmodelu etapu 3, widok etapu 3 przechowuje te dane w hidden fieldach, itd.

0
somekind napisał(a):

No np. dane z etapu 1 przesyłasz na kontroler, ten je dodaje do viewmodelu etapu 2, widok etapu 2 przechowuje te dane w hidden fieldach, a potem odsyła do kontrolera, ten dodaje dane z etapu 1 oraz 2 do viewmodelu etapu 3, widok etapu 3 przechowuje te dane w hidden fieldach, itd.

po co trzymać dane w pamięci / bazie i przesyłać jakiegoś guida, gdy można żonglować wieloma fieldami pomiędzy wieloma stronami :D

0

@WeiXiao: w jakiej pamięci Ty chcesz trzymać dane między requestami HTTP? I po co wstawiać do bazy jeśli można nie wstawiać?

0

@somekind:

I po co wstawiać do bazy jeśli można nie wstawiać?

W facebooku ktoś pewnie zszedł na zawał po przeczytaniu tego w kontekście zbierania danych :D

Aby móc na podstawie zapisanych danych wyciągać różne wnioski.

np. 130 razy klienci dodali do koszyka iPhone XYZ, ale na etapie płacenia rezygnowali - dlaczego?

A gdyby im wysłać na maila ofertę - iPhone XYZ 15% discount?

A może mamy zbyt mało dostępnych opcji płatności?

Generalnie telemetria.

w jakiej pamięci Ty chcesz trzymać dane między requestami HTTP?

Jeżeli jest to aplikacja jednoinstancyjna, to w pamięci aplikacji - static ConcurrentDictionary<T, K>

1
WeiXiao napisał(a):

Generalnie telemetria.

A skąd Ci się urodziła tutaj telemetria?

Jeżeli jest to aplikacja jednoinstancyjna, to w pamięci aplikacji - static ConcurrentDictionary<T, K>

No to kolejne dziwne założenie, które dodałeś.

To może jeszcze trzeba dodać stepujące psy Dingo jak format wymiany danych, bo a nuż aplikacja ma być dostępna dla niewidomych Aborygenów?

0

@somekind:

A skąd Ci się urodziła tutaj telemetria?

Bo zbierając te dane w bazie masz dodatkowo telemetrię

In software, telemetry is used to gather data on the use and performance of applications and application components, e.g. how often certain features are used, measurements of start-up time and processing time, hardware, application crashes, and general usage statistics and/or user behavior.


No to kolejne dziwne założenie, które dodałeś.

No to nadal możesz użyć bazy jeżeli masz wiele instancji

0

Ja nie przeczę, że JEŚLI chce się mieć telemetrię lepiej użyć bazy. Ja piszę, że obecnie NIE MA takiego założenia, więc nie ma sensu optować za tym na tej podstawie. OP nie pisał nic o tym, że częścią jego problemu jest zbieranie danych telemetrycznych. Za to pisał, że dane finalnie mają trafić do bazy.
Wstawianie tymczasowych danych do bazy, niesie za sobą pewne negatywne konsekwencje, jak chociażby konieczność zapewnienia ich transakcyjności, utrudnione testowanie czy czyszczenie w przypadku, gdy ktoś nie dokończy procesu. Jeśli nie będzie z tego żadnego zysku, to po co utrudniać sobie życie?

Zresztą, nawet gdyby chcieć implementować telemetrię, to winno się to zrobić jako dodatek do procesu biznesowego, a nie jako jego część. Ergo, nie powinna korzystać z tego samego miejsca przechowywania danych co biznes, a ponadto jej dodanie w razie potrzeby jest jak najbardziej możliwe także przy podejściu, które je zaproponowałęm.

0

Już pomijając zasadność, bo to zależy od OPa, to wydaje mi się, że demonizujesz ten dość prosty proces - to jest tylko INSERT i SELECT do bazy. Dane są immutable, bo mają one charakter logów.

Utrudnione testowanie to też chyba mocno przesadzony zarzut, bo ile tak naprawdę dodatkowej pracy Ci dojdzie przy unit testach? Testy frontendu się tutaj nie zmienią.

czy czyszczenie w przypadku, gdy ktoś nie dokończy procesu

No właśnie nie, nie chcemy tego usuwać, bo chcemy wiedzieć "coś" więcej, że ktoś np. na etapie 2 z 4 przerwał proces i może dojdziemy do tego Why?

A jeżeli uważasz że baza będzie Ci puchnąć, to zawsze można migrować co X(miesiąc? rok?) takie dane do jakiejś bazy dla data scientistów i tyle, ale to już zależy od aplikacji.

Jeśli nie będzie z tego żadnego zysku, to po co utrudniać sobie życie?

Masz rację :P

0
WeiXiao napisał(a):

Utrudnione testowanie to też chyba mocno przesadzony zarzut, bo ile tak naprawdę dodatkowej pracy Ci dojdzie przy unit testach? Testy frontendu się tutaj nie zmienią.

W unit testach to może nawet i w ogóle, ale unit testy to niewielka część testowania. Skoro wieloetapowy proces zamawiania ma być oparty o bazę, to trzeba poprawność każdego etapu w tej bazie sprawdzić.

No właśnie nie, nie chcemy tego usuwać, bo chcemy wiedzieć "coś" więcej, że ktoś np. na etapie 2 z 4 przerwał proces i może dojdziemy do tego Why?

No ok - ale to jest kolejna decyzja do podjęcia.

A jeżeli uważasz że baza będzie Ci puchnąć, to zawsze można migrować co X(miesiąc? rok?) takie dane do jakiejś bazy dla data scientistów i tyle, ale to już zależy od aplikacji.

No, a migracja to kolejna robota do wykonania. :P

A telemetria to właśnie od razu powinna do oddzielnej bazy dla analityków trafiać, a nie do bazy zakupowej. Zresztą, tymczasowy stan zamówienia też powinien być w oddzielnej bazie.
Jakbyś był konsultantem Oracla, to na Karolu Krawczyku zbiłbyś majątek przekonując go, że zamiast jednej bazy potrzebuje trzech. :P
Hmm, a może jesteś. :D

0

@somekind:

W unit testach to może nawet i w ogóle, ale unit testy to niewielka część testowania. Skoro wieloetapowy proces zamawiania ma być oparty o bazę, to trzeba poprawność każdego etapu w tej bazie sprawdzić.

no, i jaki z tym problem? poważnie nie rozumiem :D

masz unit testy oraz testy frontu, które przeklikają Ci cały proces od A do Z, a w między czasie, pomiędzy etapami robisz asercje na danych w bazie?

i to jest ta komplikacja? masz tylko dodać selecta + asercję do istniejących testów frontu

Chyba, że chcesz ORMa testować czy coś?

0
WeiXiao napisał(a):

i to jest ta komplikacja? masz tylko dodać selecta + asercję do istniejących testów frontu

Każdy kod, który trzeba napisać, to komplikacja. (A kod, który dodatkowo niczego nie wnosi, to komplikacja poczwórna.)

1 użytkowników online, w tym zalogowanych: 0, gości: 1