Zasady tworzenia aplikacji klient-serwer

0

Generalnie zawsze tworzyłem aplikacje "lokalne". Obecnie jestem na etapie projektowania bazy danych dla firmy. I tu kilka pytań. Na chwilę obecną jestem na etapie projektowania i tu chcę poświęcić sporo czasu. Generalnie chodzi mi o to aby wątek szedł w stronę np.
1). czy komplikacja aplikacji ma być bardziej po stronie klienta czy serwera
2). wydajność i optymalizacja
3). zmniejszenie ruchu w sieci a efektywność
4). pułapki podczas pisania w/w aplikacji
5). Logika biznesowa podczas worzenia
6). Konserwacja i administracja

Dobrze by było aby wątek przybrał formę dyskusji i nie zawierał potyczek słownych, wyższości/nizszości systemów itp.

0

Ja odpowiem trochę na punkt pierwszy.
Zależy czy platforma na jakiej jest uruchamiana aplikacja kliencka jest typowym komputerem czy cienkim klientem (w tym wliczając urządzenia mobilne). W tym drugim wypadku warto przerzucić większą część skomplikowania na stronę serwerową.
W pierwszym wypadku na przykład by nie obciążać bazy danych stosuje się dużą aplikację kliencką - także takie optymalizacje jak pobieranie "kopii" bazy danych, wykonywanie operacji na danych lokalnie, a potem jedynie synchronizacja z rzeczywistą bazą danych gdzieś na serwerze. O ile wiem .NET ładnie umożliwia takie operacje.

Ja sam jestem za komplikacją rozwiązań serwerowych, ale to dlatego, że piszę aplikacje działające w przeglądarce - w miarę możliwości każdej, zawsze, wszędzie, stąd najwięcej operacji wykonuje strona serwerowa, strona kliencka jest jedynie front-endem, a wszelkie dodatkowe operacje - przez JS, AJAX i tym podobne to jedynie dodatki zwiększające użyteczność.

0
  1. Zależnie, co to za aplikacja - najlepiej by obliczenia matematyczne były po stronie klienta, a serwer odpowiadał za połączenia i spójność danych. Pamiętaj, że łatwiej upgradeować jeden serwer niż n klientów. Pomyśl o prostym mechanizmie automatycznej aktualizacji.
  2. Jeśli to aplikacja biurowa, bardziej zainteresuj się optymalizacją połączenia niż wydajnością klienta.
  3. Jeśli to aplikacja działająca przez internet lub inną, zatłoczoną sieć, minimalizuj częstość pobierania danych do minimum. Lepiej wysłać dużą porcję rzadko, niż maleńką często. Rozważ też rozmiar MTU - nie jest opłacalnym wysłanie 1 bajta tylko by coś tam potwierdzić.
  4. Jeśli istnieje jakieś rozwiązanie przemysłowe, nie rób go od zera. Niech nie skusi cię napisanie własnego serwera baz danych na plikach typowanych (bo przecież zajmie kilkaset KB zamiast jakiegoś PostreSQL czy innego).. te systemy są duże, bo upraszają wiele rzeczy i ich jakość jest znacznie wyższa niż pisanego na szybko serwera plików typowanych (o kontroli spójności danych nie wspomnę)
  5. Logikę biznesową proponuję dać po stronie klienta o ile to architektura z grubym klientem - np.: Delphi, w przeciwnym wypadku warto rozważyć zbudowanie aplikacji webowej (powiedzmy server-side+SQL)
  6. Oj to trudne zagadnienie - aplikacje webowe są scentralizowane i łatwo je serwisować czy administrować.. jeśli możesz coś w ten sposób zrealizować, polecam.

Ważne kwestie do rozważenia:

  • czy w przypadku awarii sieci klient traci cały dostęp do danych (aplikacje webowe) czy ma dostęp - na przykład tylko do odczytu ale ma (częste w aplikacjach gruby klient z lokalnym repozytorium)
  • czy łatwo będzie wykonać kopię zapasową
  • czy łatwo będzie dokonać poprawek
  • jaką ilością danych będzie dysponowała aplikacja pod koniec cyklu życia (rok? dziesięć lat?) i ile wtedy zajmie dostęp do danych

Jeśli piszesz grubego klienta - piszesz i administrujesz 2 aplikacje: klient oraz serwer, dla cienkiego klienta jest nim najczęściej przeglądarka www więc problem upraszcza się do samego serwera.

Rozważ też na ile możesz pozwolić sobie na udostępnienie kodu (języki skryptowe). Jeśli mimo to chcesz użyć server-side, bo daje dużo możliwości, znajdź oprogramowanie do kodowania plików źródłowych.

0

Teraz na to wpadłem. Poniżej dwa linki. Jeden ze strukturą bazy (tak mniej więcej). Drugi z warunkami jakimi dysponuje firma.
http://4programmers.net/Forum/viewtopic.php?id=105588
http://4programmers.net/Forum/viewtopic.php?id=106106

Generalnie, to najbardziej bolą raporty z bazy. Czy lepiej zrobić n-zapytań do bazy, czy pobrać jeden duży zbiór danych i niech aplikacja klienta się martwi separacją i statystyką?

0
Oleksy_Adam napisał(a)

Generalnie zawsze tworzyłem aplikacje "lokalne". Obecnie jestem na etapie projektowania bazy danych dla firmy. I tu kilka pytań. Na chwilę obecną jestem na etapie projektowania i tu chcę poświęcić sporo czasu. Generalnie chodzi mi o to aby wątek szedł w stronę np.
1). czy komplikacja aplikacji ma być bardziej po stronie klienta czy serwera
2). wydajność i optymalizacja
3). zmniejszenie ruchu w sieci a efektywność
4). pułapki podczas pisania w/w aplikacji
5). Logika biznesowa podczas worzenia
6). Konserwacja i administracja

imho podejście powinno zależeć od wymagań, które chce się spełnić. Jeśli całe rozwiązanie nie musi być w miarę skalowalne (dużo użytkowników/obciążające przebiegi/failover), to wybrałbym architekturę 2-warstwową: prezentacją i logika na klientach, składnica danych to jakiś SQL serwer; w przeciwnym wypadku - 3 warstwowa, a tu do wyboru, czy to zrobić jako aplikację webową, czy jako thin-clienty i serwer(y) aplikacji.

Jeśli nie potrzebujesz skalowalności, zaoszczędzisz czasu i poziomu skomplikowania całego rozwiązania. Plusy n-warstwowej archiktetury są spore (możesz dorzucić choćby keszowania rekordów np. na poziomie serwera aplikacji, co potrafi dać niezłego kopa), ale jeśli nie jest to aplikacja webowa, to można łatwo polec, szczególnie pisząc w pojedynkę.

Zawsze można zacząć od prostszych rozwiązań, ale budując je z wykorzystaniem wzorców projektówych i mając na uwadze możliwe przyszłe modyfikacje, np. odpowiednio projektując klasy i tworząc fabryki obiektów uniezależnisz się w klasach z nich korzystających od sposobu ich tworzenia; w przyszłości możesz zmienić tylko fragment fabryki i zamiast tworzyc obiekty lokalnie będziesz mógł je tworzyć na serwerze i tam wykonywac obciążające operacje.

Nie znam szczegółów dot. Twojej aplikacji, ale zakładając, że nie będzie to aplikacja webowa, myślę, że klasyczna aplikacja c/s powinna wystarczyć; można zastosować coś w rodzaju launchera/updatera, który przed uruchomieniem właściwej aplikacji sprawdzałby, czy nie ma nowej wersji i w razie potrzeby ściągał nowe wersje plików, a dopiero potem odpalałby program.

Podsumowując, imho:

  1. zależnie od architektury
  2. podobnie, z tymże myślę, że dochodzi jeszcze kwestia, czy logika biznesowa będzie implementowana w aplikacji czy np. zaszyta w procedurach na serwerze DB. Na procedurach składowanych można sporo zyskać (gotowy plan wykonania), ale wtedy może pojawić się problem synchronizacji logiki aplikacja-serwer DB podczas modyfikacji programu.
  3. tak jak wspomniano, lepsze są "chunky calls" niż "chatty calls"; keszowania danych może pomóc, ale i skomplikować (zabezpieczanie się przed aktualizacją nieaktualnych danych)
  4. myślę że zależnie od architektury i technologii; przy 2 warstwowej aplikacji odpada sporo problemów w porównaniu do klienta-serwera aplikacji, ale już przy aplikacji webowej te plusy w zasadzie giną
  5. imho idealna sprawa to dysponowanie obiektowością, bo chyba nic lepiej nie modeluje rzeczywistości niż obiekty.
  6. zależnie od architektury; aplikacja webowa - pełen komfort, podobnie dla serwera aplikacji, ale jeśli dobrze się pomyśli, można i na zwykłej c/s zaoszczędzić sobie potencjalnych upierdliwych kłopotów przy aktualizacjach.
0

ja tylko ogólnie napiszę
Jeśli ma być serwer BD z prawdziwego zdarzenia (nie np. SQLite lokalnie, własne pliki, Paradox itp) to nie bój się go wykożystać w 100% - np. PostgreSQL daje Ci kilkanaście różnych języków, w których można pisać stored proc. Wyzwalacze, procedury to naprawdę potężne narzędzia, które pozwalają na zawarcie większości logiki w bazie. Jeśli nie masz zamiaru pisać własnego serwera aplikacji to im więcej zawrzesz w BD tym prostsze to będzie w utrzymaniu. Zauważ, że jak coś trzeba będzie poprawić (np. sposób liczenia VATu) to robisz tylko update procedury na serwerze i koniec - klient się nie zmienia.

Ogólnie jeśli aplikacji jest typowym frontendem dla bazy to tylko frontendem powinna być, tzn im mniej zależy (chodzi o sposób liczenia, tworzenia raportów itp) od klienta tym lepiej dla Ciebie.

Zwróć też uwagę, że widoki właściwie używane dają Ci ogromne możliwości - np. możesz mieć jedną formę "raporty", której zadaniem będzie tylko i wyłącznie wyświetlić jakiegoś skomplikowanego selecta w gridzie, a dane do wyświetlenia można wybierać zmieniając widok, z którego są czerpane (po stronie klienta masz prosty SELECT * FROM konkretny_widok a co robi sam widok to już w bazie jest)

takie podejście daje Ci jeszcze

  1. możliwość dość prostego sprawdzenia wszystkich zapytań wykonywanych na bazie i ich optymalizacje
  2. minimalizuje ruch - do klienta lecą tylko gotowe dane
  3. nie dajesz userowi dostępu (nie ma dostępu do poleceń typu insert, update, delete) do bazy a jedynie do procedur, które mogą weryfikować dane, jakie do nich są przekazywane
  4. wszystkie "życiowe" elementy systemu (logikę biznesową) masz w większości (koło 80 - 95%) w jednym miejscu
  5. i jeszcze jak logikę masz po stronie BD nie masz większego problemu z dorobieniem klienta np. www

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