AJAX
Myślę, że twoje pytanie sprowadza się do: „Czy moja aplikacja internetowa powinna generować HTML po stronie klienta, czy po stronie serwera?” Generowanie po stronie klienta komunikuje się z serwerem za pomocą AJAX, chociaż X (XML) zasadniczo został zastąpiony JSON, ale większość ludzi nadal nazywa go AJAX, ponieważ brzmi lepiej. Po stronie serwera, serwer tworzy po prostu HTML na serwerze.
Mam duże doświadczenie z XML-em i prawie żadne z JSON-em. Wszystko, co wiem o XML, sprawia, że sugeruję używanie JSON, jeśli to w ogóle możliwe.
Zalety AJAX:
- Wysyłaj mniej danych przez HTTP (S), aby mogły działać szybciej.
- Serwer jest zasadniczo usługą internetową, dzięki czemu inne osoby (lub Ty) mogą pisać własnych klientów. Może to pomóc przy tworzeniu mobilnej wersji witryny. Ponadto wiele wynalazków zyskuje popularność z powodów, których ich twórca nigdy nie zamierzał. Usługi są bardziej przyjazne dla osób, które znajdą nowe zastosowania dla Twojego kodu.
- Wygląda jak nowsza aplikacja
Wady AJAX:
- Debugowanie JavaScript
- Złożoność?
- Rzeczy, które możesz zrobić za pomocą JavaScript, są często całkowicie niemożliwe dla osób niewidomych lub niepełnosprawnych.
- Może wymagać więcej kodu ogółem (większa ogólna pamięć na urządzeniu wbudowanym)
Klient / serwer
Wszystkie aplikacje internetowe używają architektury klient-serwer. Protokół HTTP wymusza zachowanie aplikacji internetowych w ten sposób. AJAX stosuje obejście tego ograniczenia projektowego, ale podstawowym modelem bazowym HTTP jest nadal klient-serwer. Nie chciałbym odrywać się od wszystkiego, co do najlepszego sposobu zastosowania MVC do aplikacji internetowych. Jeśli musisz robić MVC z powodów politycznych, sprawdź, jak to robi Ruby / Rails. W rzeczywistości Railsy to świetna architektura do kopiowania (lub używania).
Usługa kontra aplikacja.
Dobra usługa jest prawie zawsze lepsza niż aplikacja. Ale wykonanie dobrej usługi jest trudne! Być może trzeba będzie złożyć wniosek, zanim będzie można napisać wystarczająco dobrze zaprojektowaną specyfikację dla usługi. Nie rób trudniejszej pracy niż trzeba. W wersji 1 skoncentruj się na stworzeniu świetnej aplikacji. Dopóki twoja aplikacja nie będzie względnie stabilna i nie będziesz pewny, że spełnia ona wymagania użytkownika, posiadanie usługi prawdopodobnie i tak nic ci nie da. Zbyt wczesne projektowanie niewłaściwej usługi to strata czasu, którą trzeba tracić, próbując naprawić interfejs usługi i zajmując się masowym refaktoryzowaniem kodu serwera i klienta, który nastąpi.
C / Web
Łał. Pracowałem w C and Assembly przez 3 lata, zanim przestawiłem się na tworzenie stron internetowych. Nie mogę wymyślić gorszego języka do pisania aplikacji internetowych - szczególnie z punktu widzenia bezpieczeństwa. Sprawdzanie poprawności danych wejściowych i zmiany wartości wyjściowych są tak krytyczne ... SANS publikuje listę najczęstszych błędów każdego roku. Przepełnienia bufora, zastrzyki, problemy między witrynami (nieprawidłowe kodowanie danych wyjściowych) ... Wszystkie te błędy są naprawdę łatwe do wykonania w C lub w asemblerze. Przynajmniej język taki jak Java ma ciąg znaków, który jest odporny na przepełnienia, oraz mechanizm obsługi wyjątków, który na ogół zapobiega błędnym kodom dostępu do pamięci systemowej. Nie wspominając już o obsłudze międzynarodowych zestawów znaków (w miarę możliwości używaj UTF-8 ).
Jeśli musisz użyć C ze względu na pamięć lub oprogramowanie układowe, musisz to zrobić. Tylko bądź ostrożny!
Obsługa przeglądarki
Pierwszym krokiem do stworzenia aplikacji internetowej jest odkrycie, które przeglądarki będą używane przez Twoich klientów? W3Schools i Wikipedia są dobrym źródłem ogólnych statystyk, ale YMMV.
W miejscu, w którym teraz pracuję, obecnie potwierdzamy, że nasza aplikacja tworzy tylko poprawny przejściowy kod HTML XHTML 1.0. Używamy również określonego Doctype i formatowania niezbędnych do uniknięcia Trybu dziwactwa w IE, co ułatwia pisanie HTML w różnych przeglądarkach (zobacz wskazówki na moim blogu ). Testujemy na najnowszych 3 wersjach IE, a także Firefox i Chrome w systemach Windows i Linux (Safari używa tego samego silnika renderowania co Chrome). Dzięki tej weryfikacji i testowaniu nasza aplikacja działa prawie wszędzie (Windows, Mac, Linux, iPhone, Android itp.) Oprócz BlackBerry.
BlackBerry nigdy nie miał prawdziwej przeglądarki z JavaScriptem, więc nie obsługujemy go. Użytkownicy BlackBerry są przyzwyczajeni do tego, że nie mają prawdziwej przeglądarki internetowej, więc nie narzekają. Może to się zmienia? Spróbuję zapytać kilku klientów, jakich przeglądarek używają, i upewnij się, aby przetestować te przeglądarki.
streszczenie
Wszystkie strony internetowe są oparte na HTML i HTTP. Podczas tworzenia aplikacji miej dobre informacje na temat tych technologii. Podczas tworzenia aplikacji, nawet z zestawem narzędzi, natkniesz się na problemy wymagające podstawowej znajomości tych technologii w celu ich rozwiązania.
Prawdopodobnie musisz także czuć się komfortowo z CSS i kompresją obrazu, aby stworzyć coś, co wygląda przyzwoicie i szybko reaguje. JavaScript, serwery sieciowe i przeglądarki to dodatkowe obszary wiedzy, których ostatecznie będziesz potrzebować.
Jeśli zbudujesz HTML po stronie serwera, Twoja baza kodu prawdopodobnie będzie mniejsza i nie będziesz musiał uczyć się JavaScript. Model po stronie serwera oznacza, że programiści będą pisać (C?) Kod, który generuje HTML, na który mogą spojrzeć bezpośrednio przed wysłaniem go do klienta. Model AJAX oznacza, że programiści będą pisać JavaScript, który generuje HTML. Nie znam wielu narzędzi do sprawdzania poprawności, a nawet przeglądania kodu HTML generowanego przez JavaScript w przeglądarce, co utrudnia prawidłowe programowanie.
Tam, gdzie teraz pracuję, stosujemy podejście hybrydowe, które czasami obejmuje kod Java, który generuje JavaScript, który generuje HTML. Jeśli jesteście nowicjuszami w tworzeniu stron internetowych, nie jest to miejsce na początek. Chyba muszę powiedzieć, że jeśli nie masz istotnych powodów, aby używać modelu AJAX, zacznę od starszego modelu generowania HTML po stronie serwera i sprawdzę, jak daleko cię to zaprowadzi.