Przenosisz całą logikę interfejsu użytkownika na stronę klienta?

9

Nasz zespół pierwotnie składał się głównie z programistów po stronie serwera z minimalną wiedzą specjalistyczną w zakresie Javascript. W ASP.NET pisaliśmy dużo logiki interfejsu użytkownika w kodowaniu lub ostatnio przez kontrolery w MVC.

Jakiś czas temu do naszego zespołu dołączyło 2 programistów wysokiego poziomu. Mogą robić w HTMl / CSS / JavaScript prawie wszystko, co wcześniej mogliśmy zrobić z kodem po stronie serwera i kontrolkami sieci po stronie serwera:

  • Pokaż / ukryj elementy sterujące
  • Dokonaj walidacji
  • Kontroluj odświeżanie AJAX

Zacząłem więc myśleć, że być może bardziej efektywne byłoby po prostu utworzenie interfejsu API wysokiego poziomu wokół naszej logiki biznesowej, podobnie jak Amazon Fulfillment API: http://docs.amazonwebservices.com/fws/latest/APIReference/ , aby ten klient programiści poboczni w pełni przejmą interfejs użytkownika, podczas gdy programiści po stronie serwera skoncentrują się wyłącznie na logice biznesowej.

Tak więc do zamawiania systemu miałbyś interfejs API wysokiego poziomu, taki jak:

OrderService.asmx

CreateOrderResponse CreateOrder(CreateOrderRequest)
AddOrderItem
AddPayment
-
SubmitPayment
-
GetOrderByID
FindOrdersByCriteria
...

Byłby dostęp do JSON / REST do API, więc łatwo byłoby korzystać z interfejsu użytkownika po stronie klienta. Możemy użyć tego interfejsu API zarówno do tworzenia wewnętrznych interfejsów użytkownika, jak i do tworzenia własnych aplikacji dla stron trzecich.

Dzięki postępom w Javascript i dostępności dobrych programistów po stronie klienta, czy to dobry moment, aby pozbyć się koderów / kontrolerów i skoncentrować się na tworzeniu interfejsów API wysokiego poziomu (ala Amazon), które programiści po stronie klienta mogą konsumować?

javascript architecture asp.net team enterprise-architecture Mag20
źródło

Odpowiedzi:

6

Sprawdzanie poprawności po stronie klienta w celu odciążenia po stronie serwera i zwiększenia odpowiedzi aplikacji jest w porządku, ale zawsze sprawdzaj poprawność po stronie serwera. Można wyłączyć JavaScript, a przy bezpośrednim użyciu interfejsu API REST JavaScript nigdy nie będzie potrzebny.

Htbaa
źródło
Tak, sprawdzanie poprawności byłoby również częścią domeny / interfejsu API. Po stronie klienta pobierałby z API to, co należy zweryfikować, lub dokumentowaliśmy, co jest wymagane itp. Dla każdej metody. Jeśli nadal występują błędy sprawdzania poprawności po stronie klienta - zgłaszamy wyjątki.
Mag20
4

Należy pamiętać, że złożone interfejsy użytkownika mogą wymagać dodatkowej warstwy „asystenta interfejsu użytkownika” do obsługi takich rzeczy, jak hierarchie, relacje master / detail i inne koncepcje interfejsu użytkownika, które tak naprawdę nie istnieją w warstwie biznesowej. Często nie jest możliwe wdrożenie niektórych z tych funkcji bez wielokrotnych podróży w obie strony do warstwy biznesowej, co obniża wydajność. Przynajmniej wolę warstwę „Pomoc interfejsu użytkownika” niż bezpośredni dostęp interfejsu użytkownika do bazy danych.

TMN
źródło