Lokalnie czy na serwerze?

Kilka razy na tydzień czy nawet dziennie, wypełniamy w przeglądarce formularze. Czy to pola do logowania w aplikacji, czy to formularz zamówienia, rejestracji w serwisie czy może komentarz na forum? Każdy z tych formularzy ma określoną liczbę pól, istotną dla danej operacji. Wypełniając formularz nie zastanawiamy się jednak na tym, że pod nim kryje się dodatkowa logika. Tę logikę zauważamy, gdy ominiemy pole lub wpiszemy błędną wartość. Otrzymujemy odpowiedni komunikat, a potem wprowadzamy uzupełnienia i wysyłamy formularz. Działanie to przedstawia poniższy proces.

W powyższym procesie zakładamy, że po wysłaniu formularza jest wykonywana walidacja sposobu jego wypełnienia. Walidacja taka może odbyć się lokalnie, zdalnie (tj. na serwerze) lub w każdym z tych miejsc. Walidacja wykonywana lokalnie przeważnie nie wymaga komunikacji z serwerem i jest wykonywana przez przeglądarkę użytkownika (np. przy użyciu tzw. Java Script, o czym więcej pod linkiem na końcu wpisu). Walidacja wykonywana zdalnie (na sewerze) wymaga przesłania danych do serwera i poczekania na jego odpowiedź.

Jak widać na diagramie, mamy 2 ścieżki – lokalną na zielono oraz z wykorzystaniem serwera na żółto. Na obydwu ścieżkach wystąpienie błędu (oznaczonego obiektem error event) powoduje powrót do formularza. W pierwszym przypadku formularz do serwera jest przesyłany o 1 raz mniej niż w drugim przypadku.

Częścią wspólną są zdarzenia: początkowe, czyli Zaakceptowany formularz oraz końcowe, czyli Formularz poprawny oraz Formularz niepoprawny. W ramach części procesu, są podobne kroki, ale wykonywane w innych miejscach. Chcąc wdrożyć mechanizmy po obywdu stronach można wykorzystać różne języki programowania i metody. Jak widać w podlinowanym artykule możliwości jest wiele i w zależności od sposobu zaprojektowania rozwiązania mechanizmy są rozdzielone lub silnie ze sobą powiązane (jak np. przy wykorzystaniu AJAX).

Reklama

Oczekując na zdarzenie

Telefon z recepcji hotelowej przypomniał mi o moim zamówieniu. Informacja była prosta, że w tej chwili nie mogą zrealizować zamówienia. Powiedziałem, że mogę poczekać nawet godzinę. No właśnie, złożyłem zamówienie i czekałem na wynik, w sumie nieistotne było dla mnie jakie czynności przed czy po telefonie wykonują żeby zrealizować moje zamówienie. Czy sprawdzają listę zamówień? Czy pytają tych co się opóźniają ze zwrotami? Jak się komunikują między recepcją a osobami realizującymi? Dla mnie ważny jest efekt, że po zgłoszeniu zamówienia, po jakimś czasie mogę się spodziewać pukania do drzwi. Oczekuję jakby na określone zdarzenie, a dokładniej zareaguję na zdarzenie, które nastąpi.

W ten sposób działa proces w przypadku tzw. czarnej skrzynki. W centrum zainteresowania są operacje, komunikaty wykonywane/wysyłane przez jedną ze stron i ich efekt. Na powyższym diagramie recepcję/obsługę można traktować jako czarną skrzynkę.

Czas między zgłoszeniem a zdarzeniem „pukania do drzwi” może wpłynąć na:

• ocenę realizacji procesu, jego efektywności,
• postępowanie w przyszłości, że wcześniej zacznę proces (wcześniejsze zgłoszenie),
• ewentualne skrócenie czasu, który będę oczekiwać na realizację,
• rezygnację z usług i realizację ich w inny sposób,
• ewentualne zasygnalizowanie czasu akceptowalnego oczekiwania w momencie zgłoszenia.

Z punktu widzenia recepcji/obsługi, mogą wpisać w informacji dla gościa, że czas oczekiwania na zamówienie może trwać tyle i tyle, a także w którym momencie gość zostanie powiadomiony o przedłużeniu czasu realizacji – podobnie jak w przypadku rozpatrywania reklamacji.

W zależności od punktu widzenia, wnioski są różne. W przypadku recepcji/obsługi przyjęcie zamówienia jest podobnym punktem, ale zgłoszenie możliwości odbioru jest jeszcze ważniejszym, ponieważ oznacza, że można zrealizować kolejne zamówienie innego gościa, który także ocenia proces realizacji, o innych lub podobnych akceptowalnych parametrach.