Moduły w programie - jakie waszym zdaniem najlepsze rozwiązanie?

Witam Was,

Zastanawiam się jakie rozwiązanie polecacie i dlaczego jeżeli piszecie aplikację do której można dodawać moduły. Aby rozmiar pliku wykonywalnego w delphi nie miał np. 60mb lub wysyłacie program w okrojonej wersji :) Aby było prościej zakładamy że piszemy aplikację np do firmy ( która w standardzie ma np możliwość wystawiania dokumentów sprzedaży + magazyn ) która powiedzmy będzie zawiera takie moduły dodatkowe:

• obsługa sklepu prestashop
• obsługa sklepu magento, itp
• obsługa firmy kurierskiej X ( generowanie listów, śledzenie itp )

Czy dobrym rozwiązaniem były by np. biblioteki dll z formularzami?

W zasadzie dll chyba właśnie do tego zostały stworzone? Według mnie to najlepsze rozwiązanie ale chętnie poczytam opinie innych.

robertz68 napisał(a):

W zasadzie dll chyba właśnie do tego zostały stworzone?

Biblioteki te stworzone zostały po to, aby pewien zbiór danych i funkcji mógł być wykorzystywany przez inne biblioteki i aplikacje (bez względu na język programowania, w jakim zostały one napisane). Każdy moduł może skorzystać z zawartości biblioteki, pod warunkiem że zna się nagłówki czy uchwyty.

A to że pluginy do programów tworzy się w postaci bibliotek .dll, to tylko kolejny sposób wykorzystania pierwotnych założeń ich istnienia. Sporo aplikacji tak właśnie zapewnia wsparcie wtyczek.

Rafał D napisał(a):

Czy dobrym rozwiązaniem były by np. biblioteki dll z formularzami?

U mnie pisze się właśnie w ten sposób. Całość piszemy w dll'kach które eksportują odpowiednie funkcje wyświetlające okienko. Oczywiście są również i inne metody. Każdy moduł siedzi w oddzielnej dll'ce. Plik główny exe ma za zadanie tylko utworzyć wszystkie obiekty, dokonać logowania do systemu i wywoływać odpowiednie metody wyświetlające okna po wybraniu z menu głównego żądanej opcji.

Co do exe'ca o wadze 60MB to nie miałbym nic przeciwko. W dzisiejszych czasach pojemności dysków nie są małe i nie ma różnicy czy mam 1 exe 60MB, czy 1 exe 500kB oraz 50 1-2MB plików dll. Jedyna różnica może być w szybkości uruchamiana takiej aplikacji. Jeśli tworzymy obiekty oraz ładujemy pliki dll na żądanie (dopiero gdy będą nam potrzebne), to szybkość uruchamiana aplikacji rozbitej na małe dll'ki powinna być większa. Jeśli jednak uruchamiamy wszystko podczas startu to czasy uruchamiania będą podobne.

robertz68 napisał(a):

W zasadzie dll chyba właśnie do tego zostały stworzone? Według mnie to najlepsze rozwiązanie ale chętnie poczytam opinie innych.

W Delphi?
To najgorsze rozwiązanie, zwłaszcza że jest dużo lepsza alternatywna dla Delphi, czyli BPL.

Mr.YaHooo napisał(a):

Rafał D napisał(a):

Czy dobrym rozwiązaniem były by np. biblioteki dll z formularzami?

U mnie pisze się właśnie w ten sposób. Całość piszemy w dll'kach które eksportują odpowiednie funkcje wyświetlające okienko. Oczywiście są również i inne metody. Każdy moduł siedzi w oddzielnej dll'ce. Plik główny exe ma za zadanie tylko utworzyć wszystkie obiekty, dokonać logowania do systemu i wywoływać odpowiednie metody wyświetlające okna po wybraniu z menu głównego żądanej opcji.

Fatalne rozwiązanie dla Delphi, imho...
Strasznie dużo gównianych problemów, a największy z nich - każda DLLa w Delphi posiada własną kopię RTLa (nie dość że taka DLLka jest wielka jak stodoła to wieczne problemy z przekazywaniem instancji obiektów RTL pomiędzy DLL->HOST->DLL) i wszystko co się z tym wiąże.

Co do exe'ca o wadze 60MB to nie miałbym nic przeciwko. W dzisiejszych czasach pojemności dysków nie są małe i nie ma różnicy czy mam 1 exe 60MB, czy 1 exe 500kB oraz 50 1-2MB plików dll. Jedyna różnica może być w szybkości uruchamiana takiej aplikacji. Jeśli tworzymy obiekty oraz ładujemy pliki dll na żądanie (dopiero gdy będą nam potrzebne), to szybkość uruchamiana aplikacji rozbitej na małe dll'ki powinna być większa. Jeśli jednak uruchamiamy wszystko podczas startu to czasy uruchamiania będą podobne.

Nie, nie będzie podobna ta szybkość.
Po pierwsze jeden exe będzie dużo, DUUUUŻOOOOO mniejszy niż suma wielu DLL, które zawierają jak to napisałeś formatki.
Złożyłbym się, ale to powszechnie znany fakt...

Po drugie - w jednym exe konsolidator posprząta.
W DLL każda biblioteka posiada własne śmieci z RTLa, mimo tego, ze inne posiadają to samo.
Ładowanie takiego DLLa to inicjacja wielu obiektów, często nawet robiona niejawnie.
Ładowanie wielu DLL, to wielokrotna inicjacja tego samego - po każdej kopii dla jednej DLL.

Żadnych tych problemów nie posiadają BPLe, ale mają inne wady, a główna to:
wszystkie BPL i host (czyli exe) musza być skomplikowane w tej samej wersji kompilatora.
Jeżeli używa się DLL, zwłaszcza zgodnych z COM, ten problem nie istnieje.

https://4programmers.net/Delphi/Artykuły/Wtyczki_(Plugin)_w_oparciu_o_interfejsy fajny artykuł o wtyczkach

wloochacz napisał(a):

Fatalne rozwiązanie dla Delphi, imho...
Strasznie dużo gównianych problemów, a największy z nich - każda DLLa w Delphi posiada własną kopię RTLa (nie dość że taka DLLka jest wielka jak stodoła to wieczne problemy z przekazywaniem instancji obiektów RTL pomiędzy DLL->HOST->DLL) i wszystko co się z tym wiąże.

Fakt zapomniałem. Kiedyś o tym dyskutowaliśmy już na forum. Na co dzień piszę w C++ Builderze i tam aby każda dll'ka posiadała wspólny RTL wystarczy linkować dynamicznie pliki *.bpl zawierające RTL'a. W Delphi z tego co pamiętam działa to inaczej. Zatem moja wina i w zasadzie mój post nie odnosi się do Delphi, a C++ Builder'a.

wloochacz napisał(a):

Nie, nie będzie podobna ta szybkość.
Po pierwsze jeden exe będzie dużo, DUUUUŻOOOOO mniejszy niż suma wielu DLL, które zawierają jak to napisałeś formatki.
Złożyłbym się, ale to powszechnie znany fakt...

W sumie nie zastanawiałem się nigdy nad tym, jednak jeśli włączymy opcję 'Dynamic RTL' oraz 'Build with runtime packages' narzut na poszczególny dll nie powinien być zbyt wielki. Jednak aż kiedyś sprawdzę z ciekawości.

wloochacz napisał(a):

Po drugie - w jednym exe konsolidator posprząta.
W DLL każda biblioteka posiada własne śmieci z RTLa, mimo tego, ze inne posiadają to samo.
Ładowanie takiego DLLa to inicjacja wielu obiektów, często nawet robiona niejawnie.
Ładowanie wielu DLL, to wielokrotna inicjacja tego samego - po każdej kopii dla jednej DLL.

Racja, jednak cały czas miałem na myśli sytuację z jednym wspólnym RTL'em.

wloochacz napisał(a):

Żadnych tych problemów nie posiadają BPLe, ale mają inne wady, a główna to:
wszystkie BPL i host (czyli exe) musza być skomplikowane w tej samej wersji kompilatora.
Jeżeli używa się DLL, zwłaszcza zgodnych z COM, ten problem nie istnieje.

Tak, chociaż zwykłe pliki DLL które eksportują klasy oraz używają wspólnego RTL'a też muszą być kompilowane tą samą wersją kompilatora, z dokładnością do wszystkich łatek.Więc tutaj w sumie jest 1:1. Ideałem było by używanie w funkcjach eksportowanych z dll tylko typów prostych (zamiast Ansi/Unicode String trzeba by się użerać z tablicami znaków) i tylko funkcji. Wtedy można by było pisać nawet w innych językach pluginy i tak właśnie większość aplikacji robi gdzie pluginy mogą pisać inni, niezależni od producenta programu developerzy.

abrakadaber napisał(a):

https://4programmers.net/Delphi/Artykuły/Wtyczki_(Plugin)_w_oparciu_o_interfejsy fajny artykuł o wtyczkach

Artykuł może i fajny, ale...
Widziałeś ile trzeba napisać kodu, żeby zrobić bardzo proste rzeczy?
A to dopiero początek...
Może inaczej - jeśli ta wtyczka,, to jest cały program de-facto, który niekoniecznie musi współdzielić obiekty z hostem i innymi wtyczkami, to OK.
Może se tak być (DLLki,COMy, itd.), ale dalej nie wiem po co.

Natomiast jeśli te wtyczki nie są tak banalne i niosą ze sobą, powiedzmy, coś na kształt mikroserwisów, to... Trzeba mieć bardzo dużo czasu, aby ointerfejsować wszystko (a jakże da się, sam mam gdzieś stary kod z np. TDataSet w wersji COM - stare dzieje...), bo inaczej to po prostu nie zadziała.

Mr.YaHooo napisał(a):

wloochacz napisał(a):

Żadnych tych problemów nie posiadają BPLe, ale mają inne wady, a główna to:
wszystkie BPL i host (czyli exe) musza być skomplikowane w tej samej wersji kompilatora.
Jeżeli używa się DLL, zwłaszcza zgodnych z COM, ten problem nie istnieje.

Tak, chociaż zwykłe pliki DLL które eksportują klasy oraz używają wspólnego RTL'a też muszą być kompilowane tą samą wersją kompilatora, z dokładnością do wszystkich łatek.Więc tutaj w sumie jest 1:1.

Skoro tak, to po co męczyć się z DLLką?
Naprawdę nie widzę najmniejszego sensu i nieważne czy to Delphi czy C++ Builder.

Ideałem było by używanie w funkcjach eksportowanych z dll tylko typów prostych (zamiast Ansi/Unicode String trzeba by się użerać z tablicami znaków) i tylko funkcji.

OK, ale to trochę drut a nie "plugin".
Ale prawda, dużo też zależy co to za pluginy, co mogą robić i jak mają to robić.

Wtedy można by było pisać nawet w innych językach pluginy i tak właśnie większość aplikacji robi gdzie pluginy mogą pisać inni, niezależni od producenta programu developerzy.

Jeśli pluginy mieliby rozwijać inni, to albo COM albo serwer aplikacyjny z implementacją pluginów w językach interpretowanych.