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:
- zależnie od architektury
- 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.
- 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)
- 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ą
- imho idealna sprawa to dysponowanie obiektowością, bo chyba nic lepiej nie modeluje rzeczywistości niż obiekty.
- 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.