Moim głównym zadaniem jest tworzenie aplikacji HTML. Mam na myśli wewnętrznie używane aplikacje typu CRUD z dużą ilością edytowalnych widoków siatki, pól tekstowych, rozwijanych menu itp. Obecnie używamy formularzy internetowych ASP.NET, które wykonują zadanie, ale wydajność jest w większości ponura i często musisz skakać przez obręcze, aby zdobyć to, czego potrzebujesz. Obręcze zwisające z sufitu i podpalające.
Zastanawiam się więc, czy dobrym pomysłem byłoby przeniesienie całego interfejsu użytkownika na stronę JavaScript. Opracuj silny zestaw kontrolek wielokrotnego użytku, które są specjalnie dostosowane do naszych potrzeb, i wymieniaj dane tylko z serwerem. Tak, podoba mi się paradygmat „kontrolny” (aka „widget”), który jest całkiem odpowiedni dla takich aplikacji. Tak więc po stronie serwera nadal będziemy mieli podstawowy układ podobny do naszego obecnego znacznika ASPX, ale wtedy zostanie on wysłany do klienta tylko raz, a część Javascript zajmie się wszystkimi kolejnymi aktualizacjami interfejsu użytkownika.
Problem w tym, że nigdy wcześniej tego nie robiłem i nigdy nie widziałem, żeby ktoś to robił, więc nie wiem, jakie byłyby problemy. W szczególności martwię się o:
- Wydajność wciąż. Benchmarking pokazuje, że obecnie główne opóźnienie występuje po stronie klienta, gdy przeglądarka próbuje ponownie renderować większość strony po aktualizacji AJAX. Znaczniki generowane przez formaty WWW ASP.NET nadają nowe znaczenie słowu „web”, a bogate formanty Devexpress dodają do tego własną warstwę złożoności Javascript. Ale czy szybsze byłoby ponowne obliczenie wszystkich niezbędnych zmian po stronie Javascript, a następnie zaktualizowanie tylko tego, co należy zaktualizować? Pamiętaj, że mówię o formularzach, które mają kilka edytowalnych widoków siatki, wiele pól tekstowych, wiele list rozwijanych, z których każda zawiera pół zillionów elementów do filtrowania itp.
- Łatwość rozwoju . Teraz byłoby o wiele więcej Javascript i prawdopodobnie mieszałoby się ze znacznikami HTML strony. Taki lub jakiś nowy silnik widoku musiałby zostać wyprodukowany. Intellisense dla Javascript jest również znacznie gorszy niż dla kodu C #, a ze względu na dynamiczny charakter Javascript nie można oczekiwać, że będzie znacznie lepszy. Praktyki kodowania mogą to nieco poprawić, ale niewiele. Ponadto większość naszych programistów to przede wszystkim programiści C #, więc będzie trochę krzywej uczenia się i początkowe błędy.
- Bezpieczeństwo . Wiele kontroli bezpieczeństwa będzie musiało zostać wykonanych dwukrotnie (po stronie serwera i interfejsu użytkownika), a strona przetwarzająca dane będzie musiała zawierać o wiele więcej. Obecnie, jeśli ustawisz pole tekstowe jako przeznaczone tylko do odczytu po stronie serwera, możesz polegać na tym, że jego wartość nie zmienia się podczas obchodu klienta. Struktura ma już wystarczającą ilość kodu, aby to zapewnić (poprzez szyfrowanie viewstate). Dzięki podejściu opartemu tylko na danych staje się trudniejsze, ponieważ musisz ręcznie sprawdzić wszystko. Z drugiej strony być może luki w zabezpieczeniach będą łatwiejsze do wykrycia, ponieważ będziesz mieć tylko dane do zmartwienia.
Podsumowując, czy to rozwiąże nasze problemy, czy pogorszy je? Czy ktoś kiedykolwiek próbował tego i jakie były wyniki? Czy istnieją jakieś ramy, które pomagają w tego rodzaju przedsięwzięciach (pomijając jQuery i równoważniki moralne)?
So on the server side we would still have a basic layout simliar to our current ASPX markup, but that then would get sent to the client only once, and the Javascript part would take care of all the subsequent UI updates.Opisujesz dokładnie, czym jest ASP.NET, co mówi mi, że prawdopodobnie nie używasz go poprawnie. :) W aplikacjach ASP.NET, jeśli umieścisz komponenty w panelach aktualizacji, biblioteka javascript ASP.NET wykona asynchroniczne aktualizacje po stronie serwera i tylko ponownie wyrenderuje określone komponenty.