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.

Przejrzałem ten wątek i nie do końca rozumiem, co OP chce uzyskać.

Po pierwsze (jak już ktoś wcześniej pisał) rozmiar 60MB to wcale nie jest dużo. Poza tym, jeśli mówimy o rozmiarze EXE'ka - czy w jakiś sposób go "zgniatałeś" - chociażby przez wywalenie informacji debuggera? W necie jest wiele materiałów odnośnie zmniejszania wielkości binarki - chociażby https://stackoverflow.com/questions/3199476/what-can-i-do-to-reduce-my-executables-size-delphi.

A po drugie - czym innym jest możliwość dodawania pluginów/dodatkowych funkcjonalności, a czym innym blokowanie dostępu do funkcji, których dany użytkownik nie ma wykupionych. Nie wiem, w jaki sposób prowadzisz licencjonowanie, ale podejrzewam, że jakoś to robisz ;) Czy to apka się łączy z serwerem i pobiera informacji o swoich modułach w oparciu o klucz licencji, czy może stosujesz klucze sprzętowe HASP. Tak czy siak - jakoś musisz mieć to rozwiązane. W każdym razie - jeśli chodzi o odcięcie użytkownika od dostępu do niewykupionych funkcji, to bym zrobił tak, żeby wszystko było w EXE, a potem podczas uruchamiania część z rzeczy będzie schowana.

Z dll jest taki problem, że jeśli z jakiegoś powodu któraś zaginie, program panikuje i mamy problem. Trzymając wszystko w jednym pliku zabezpieczamy się przed taką opcją.

wloochacz napisał(a):

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

Tak, to prawda. Jednak u mnie w pracy akurat upraszcza to współpracę. Każdy pisze swoją dll'kę niezależnie i już. Interfejs zewnętrzny tych dll'ek zmienia się raz-dwa na rok, więc można pisać bardzo niezależnie swoje moduły bez potrzeby rekompilacji wszystkiego co chwila.

wloochacz napisał(a):

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ć.

Niestety coś za coś. Sam pisałem takie pluginy gdzie funkcje operowały na typach prostych. Wtedy pisałem swój adapter zamieniający np. tablice znaków na UnicodeStringi. Inaczej ciężko posługiwać się wszędzie char*.

wloochacz napisał(a):

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

Warto rozważyć takie coś. Wszystko zależy, jak zauważyłeś co one mają robić. Bawiłem się w pisanie pluginów do Winampa. Tam wystarczyło po prostu parę funkcji eksportowanych i już plugin gotowy. W bardziej zaawansowanych przypadkach rzeczywiście łatwiej zrobić coś w stylu COM.

Dzięki Wszystkim za dyskusję. Na pewno z niej wyciągnę wnioski. Chyba blokowanie funkcji było by najprostszym rozwiązaniem. :)

Jednak dlaczego myślałem o dodatkowych funkcjach jako pluginach?
Przykład allegro wygasza swoje WebApi i zastępuje RestApi. W swoich różnych aplikacjach korzystałem z webapi i wiem ile jest potem zabawy aby całą funkcjonalność przenieść do nowego programu a tak to np skopiowanie tylko dll i obsłużenie kodu. Ale chyba jednak zostanę przy rozwiązaniu takim że RestApi w osobnych unitach tak jak to robiłem z webapi.

@cerrato: jak sie technicznie ogarnia taką aplikację gdzie część funkcji jest ukryta dla konkretnej licencji? Nie ma ryzyka, że taki Shalom wpadnie i odpali sobie full wersje?

karpov napisał(a):

@cerrato: jak sie technicznie ogarnia taką aplikację gdzie część funkcji jest ukryta dla konkretnej licencji?

Wtrącę się. ;)

Normalnie się robi – dodaje się do źródeł wszystkie możliwe funkcjonalności, ale to czy je udostępnić użytkownikowi czy nie zależy od zewnętrznego parametru (np. danych ”ukrywanych” w rejestrze lub w gdzieś głęboko zaszytych plikach). Natomiast w kodzie programu, w miejscu gdzie uruchamia się daną funkcję, najpierw sprawdza się czy użytkownik ma prawo do skorzystania z niej. Jeśli tak to się ją uruchamia, a jeśli nie to wyświetla komunikat – prosty warunek.

Tego typu dane wczytuje się już podczas rozruchu aplikacji, aby od samego początku program wiedział jak się uruchomić (np. wyświetlić monit o rejestracji lub zablokować rozruch, jeśli trial wygasł). Natomiast program może w trakcie działania modyfikować swój stan, tak aby można było zarejestrować aplikację bez potrzeby jej wyłączania (np. po podaniu seriala). Wszystko zależy od przypadku.

Nie ma ryzyka, że taki Shalom wpadnie i odpali sobie full wersje?

Oczywiście że jest, dlatego jeśli już zdecydujesz się na takie rozwiązanie, to musisz tę aplikację odpowiednio zabezpieczyć. Rozwiązań jest mnóstwo, jednak zdeterminowany cracker prędzej czy później złamie zabezpieczenia, o ile ich łamanie ma jakąkolwiek wartość (np. aplikacja jest bardzo popularna, ale droga).

Jedynym rozwiązaniem dobrze blokującym dostęp do dodatkowych funkcji jest wersja okrojona (typowa demówka), do której nie wkompilowuje się kodu tych funkcji i której kod napisany jest na sztywno (np. korzysta z predefiniowanej listy plików binarnych z danymi, zamiast sprawdzać ile ich jest i korzystać ze wszystkich). Jednak problemem w dalszym ciagu jest podmiana pliku wykonywalnego (crack), który i tak mimo wszystko zniweczy cały trud.

Zawsze można odpalić narzędzie do szpiegowania zmian na dysku i prześlecić co dany proces robi, do których plików się odwołuje i w którym momencie. Następnie zmodyfikować kod pliku wykonywalnego w taki sposób, aby ominąć jakąkolwiek walidację. Nie jest to łatwe (jak zresztą cały RE), ale nie jest też niewykonalne.

@karpov: czy wyjaśnienia złożone przez Nerwowego są wystarczające? ;)

Ja że swojej strony mogę dodać, że przed radzieckimi hackerami nie ma obrony. Tylko takie małe śmieszne robaczki jak my tutaj na tym forum nie mają się czego obawiać, nasza radosna twórczość jest zbyt mało popularna i zbyt tania, żeby komuś chciało się bawić w łamanie zabezpieczeń. Problem maja autorzy popularnych gier (cena średnia, ale ogromną ilość użytkowników) oraz programów specjalistycznych typu CAD albo Photoshop. Pewnie każdy z nas ma "kolegę", który zna kogoś, kto miał pirackiego Windows XP ;)

Odnośnie sposobu zabezpieczania - proponuję zapoznać się ze sprzętowymi kluczami HASP. Nie tylko weryfikują legalność softu, ale wspierają też różne warianty licencji. Osobiście miałem do czynienia z http://systherm-info.pl/HASP/sentinel-ldk/modele-kluczy-sentinel-hasp.html, można sobie u nich zamówić bezpłatny zestaw testowy i sobie zrobić eksperymenty w domu - http://systherm-info.pl/HASP/Sentinel-Demo/index.html.

Tak wygląda opakowanie z zestawem testowym z zewnątrz oraz po jego otwarciu:

Rafał D napisał(a):

W swoich różnych aplikacjach korzystałem z webapi i wiem ile jest potem zabawy aby całą funkcjonalność przenieść do nowego programu a tak to np skopiowanie tylko dll i obsłużenie kodu.

Skoro miałeś problem z przeniesieniem obsługi danego webapi do innego programu, znaczy, że coś miałeś skopane z architekturą programu.

Co do pytania @karpov to tak naprawdę nie ma w 100% skutecznego sposobu na zabezpieczenie się. Jeśli kod w programie jest, to zazwyczaj daje się go odblokować. Pełne bezpieczeństwo daje tylko całkowite usunięcie kodu w sytuacji gdy user nie ma licencji na dany moduł.

furious programming napisał(a):

Normalnie się robi – dodaje się do źródeł wszystkie możliwe funkcjonalności, ale to czy je udostępnić użytkownikowi czy nie zależy od zewnętrznego parametru (np. danych ”ukrywanych” w rejestrze lub w gdzieś głęboko zaszytych plikach). Natomiast w kodzie programu, w miejscu gdzie uruchamia się daną funkcję, najpierw sprawdza się czy użytkownik ma prawo do skorzystania z niej. Jeśli tak to się ją uruchamia, a jeśli nie to wyświetla komunikat – prosty warunek.

I właśnie taki prosty warunek jest do obejścia przez zwykłe script kiddie w parę chwil... Jeśli chcemy by zabezpieczenie było mocniejsze powinniśmy np. szyfrować jakieś ważne dla programu dane. Jeszcze lepiej, aby to co wprowadzi użytkownik służyło nie tylko do odblokowania funkcji, ale np. odszyfrowania kodu który jest wymagany do działania programu.

cerrato napisał(a):

Odnośnie sposobu zabezpieczania - proponuję zapoznać się ze sprzętowymi kluczami HASP. Nie tylko weryfikują legalność softu, ale wspierają też różne warianty licencji. Osobiście miałem do czynienia z http://systherm-info.pl/HASP/sentinel-ldk/modele-kluczy-sentinel-hasp.html, można sobie u nich zamówić bezpłatny zestaw testowy i sobie zrobić eksperymenty w domu - http://systherm-info.pl/HASP/Sentinel-Demo/index.html

Tu z kolei można napisać kompletny emulator i też nici z takiego rozwiązania :)

Ogólnie w zabezpieczeniach chodzi o to, aby maksymalnie utrudnić złamanie tego w sensownym czasie. Ewentualnie aby złamanie zajęło więcej niż np. wypuszczenie następnej wersji naszego softu. Wtedy to cracker będzie musiał ciągle łamać nową wersję programu.

Tutaj jest jeszcze kolejny plus kluczy HASP - o ile masz rację i zrobienie jakiegoś IF, który coś sprawdzi nie jest najpotężniejszym zabezpieczeniem, tak samo można wpiąć się gdzieś pomiędzy komunikację aplikacji z kluczem (aczkolwiek nie zgodzę się, że script kiddies sobie z tym poradzą, producenci tego typu oprogramowania naprawdę dobrze kombinują), ale jest parę innych rozwiązań, które bardzo skutecznie sobie poradzą z piratami.

Pierwsza sprawa - jeśli HASP ma jedynie potwierdzać fakt "bycia wpiętym do USB", to rzeczywiście można to w miarę nie-do-końca-trudno obejść. Nie twierdzę, że ktokolwiek po 5min filmu na YT sobie poradzi, ale jest to do zrobienia. Dlatego wymyślono wyższe poziomy zabezpieczeń. Po pierwsze - można część rzeczy w aplikacji zaszyfrować, a sposób odszyfrowania wsadzić w HASP. Nawet jak ktoś zrobi emulator, to wprawdzie program będzie miał wrażenie, że klucz jest obecny, ale nie będzie w stanie poprawnie odszyfrować zabezpieczonych treści. Jest jeszcze inna opcja, wyższy poziom zabezpieczenia - przeniesienie części aplikacji na sam klucz. Możecie sobie poczytać chociażby tutaj - http://systherm-info.pl/HASP/sentinel-ldk/technologia-apponchip.html. Owszem, wszystko się da pokonać, ale nikt z taką wiedzą i umiejętnościami nie będzie bawił się w piracenie apki ziomusia z 4programmers, sorry Panowie, ale to nie ta liga ;)

Mr.YaHooo napisał(a):

I właśnie taki prosty warunek jest do obejścia przez zwykłe script kiddie w parę chwil... […]

Nie miałem na myśli konkretnie ifa w kodzie programu, a uproszczenie wyjaśnienia do dwóch opcji. A to co będzie się za tym „warunkiem” kryło to już kwestia pomysłowości dewelopera.

furious programming napisał(a):

karpov napisał(a):

@cerrato: jak sie technicznie ogarnia taką aplikację gdzie część funkcji jest ukryta dla konkretnej licencji?

Wtrącę się. ;)

Normalnie się robi – dodaje się do źródeł wszystkie możliwe funkcjonalności, ale to czy je udostępnić użytkownikowi czy nie zależy od zewnętrznego parametru (np. danych ”ukrywanych” w rejestrze lub w gdzieś głęboko zaszytych plikach). Natomiast w kodzie programu, w miejscu gdzie uruchamia się daną funkcję, najpierw sprawdza się czy użytkownik ma prawo do skorzystania z niej. Jeśli tak to się ją uruchamia, a jeśli nie to wyświetla komunikat – prosty warunek.

Tak to się robiło dekadę/dekady temu, ale dziś robi się to ciut inaczej.
To znaczy - raczej powinno się robić inaczej, niż de-facto tak się robi...

Dlaczego?
Ano dlatego, że programiści (może właściwiej by było - koderzy) to leniwe i niedouczone typy.
A więc zamiast zaprojektować porządną architekturę w oparciu o np. DI (dependency injection) i IoC (inversion of control), to wolą robić drabinkę IFów.
Zamiast maszyny stanów - też drabinka IFów da radę...

Potem trzeba to tylko utrzymać, ale to już historia na inną bajkę...

@wloochacz: no ale to, czy korzystasz z DI czy IoC to tylko sposób techniczny, w jaki podchodzisz do samego mechanizmu obsługi i przetwarzania danych oraz sterowania aplikacją. Ale, niezależnie od tego, czy zrobisz to w ten sposób, czy drabinką IF'ów albo HASP'em, i tak musisz w jakiś sposób ustalić, do czego i w jaki sposób dany użytkownik ma mieć dostęp, więc w mojej ocenie to, o czym piszesz za wiele nie zmienia. I tak trzeba robić jakąś weryfikację/autoryzację.

wloochacz napisał(a):

Tak to się robiło dekadę/dekady temu, ale dziś robi się to ciut inaczej.
To znaczy - raczej powinno się robić inaczej, niż de-facto tak się robi...

I nadal tak się robi – wystarczy się rozejrzeć, a już przede wszystkim skupić uwagę na niedużych produkcjach. Masa softu ma prymitywne zabezpieczenia, których nawet łamać nie trzeba – wystarczy mieć seriala/keygena lub cracka, od biedy jakiś patcher (wszystko do znalezienia w minutę w sieci). Powód takiego stanu rzeczy jest raczej oczywisty.

Ano dlatego, że programiści (może właściwiej by było - koderzy) to leniwe i niedouczone typy.

Nie tylko, bo np. jeśli nie ma budżetu, to i nie ma profesjonalnych rozwiązań (nieważne czy chodzi o zespół, czy o narzędzia). Wrzucenie wszystkich przypadków do jednego worka nie ma sensu, bo nie każdy projekt to komercyjny korpo-kombajn z odpowiednim zapleczem i możliwościami.

cerrato napisał(a):

@wloochacz: no ale to, czy korzystasz z DI czy IoC to tylko sposób techniczny

Czyli jaki dokładnie?

, w jaki podchodzisz do samego mechanizmu obsługi i przetwarzania danych oraz sterowania aplikacją.

Korzystam z jednego i drugiego.
IoC leży u podstaw całej architektury, a DI jest sposobem na sprawienie aby to zaczęło działać.

Ale, niezależnie od tego, czy zrobisz to w ten sposób, czy drabinką IF'ów albo HASP'em

Nie pojmuję, co ma drabinka IFów do HASPA?

, i tak musisz w jakiś sposób ustalić, do czego i w jaki sposób dany użytkownik ma mieć dostęp,

Ładuje odpowiednie usługi, które determinują odpowiednie zachowanie/logikę aplikacji.
Nie ma tam ani jednego IFa w stylu:

if Licencja.CennikiZaawansowane then
   Caly_dziwny_kod_do_obsługi_cennikow;

więc w mojej ocenie to, o czym piszesz za wiele nie zmienia. I tak trzeba robić jakąś weryfikację/autoryzację.

Nie, nie trzeba robić weryfikacji.
Trzeba zrobił ładowania pluginów, które zdefiniowano w licencji.

Mówisz, że niewiele zmienia?
No to nie wiesz jak i po co stosuje się DI/IoC :D

no ale to, czy korzystasz z DI czy IoC to tylko sposób techniczny
Czyli jaki dokładnie?
Nie pojmuję, co ma drabinka IFów do HASPA?

Może się źle wyraziłem. Chodziło mi o to, że czy dodatkowe pluginy podepniesz do aplikacji zgodnie z w/w mechanizmami, czy jako DLL, albo może wrzucisz na stałe do kodu, a potem odpowiednio ukryjesz - tak czy siak musi być jakaś logika, która odpowiada za ustalenie, że dany klient ma mieć możliwość korzystania z danej funkcjonalności. W jakiś sposób musisz to weryfikować. A to, jak to zostanie później zrealizowane - czy jak Ty proponujesz przez wstrzykiwanie, czy jakkolwiek inaczej - to jest kwestia wtórna. A odnośnie IF/HASP - pisałem parę postów wyżej, że obecnie klucze HASP oferują znacznie więcej, niż samo sprawdzenie, czy klucz jest wsadzony w USB, obsługują m.in. szyfrowanie treści oraz dają możliwość osadzania części kodu w kluczu. Do tego producenci (chociażby podane przeze mnie linki) dostarczają bardzo fajną i obszerną dokumentację, łącznie z case study oraz poradnikami. Można tam znaleźć inspirację odnośnie tego, jak inaczej niż drabinka IF da się temat rozwiązać.

nie trzeba robić weryfikacji. Trzeba zrobił ładowania pluginów, które zdefiniowano w licencji.

Z punktu widzenia zabezpieczenia przed piratami i nielegalnym korzystaniem z treści, wiele to nie zmienia. Jak ktoś będzie chciał to wymusi załadowanie innego plugina, podmieni licencję, zafałszuje komunikację z serwerem itp.

cerrato napisał(a):

no ale to, czy korzystasz z DI czy IoC to tylko sposób techniczny
Czyli jaki dokładnie?
Nie pojmuję, co ma drabinka IFów do HASPA?

Może się źle wyraziłem. Chodziło mi o to, że czy

Ale że czy czy, bo nie wiem czy pytasz czy stwierdzasz.
Zakładam, że pytasz...

dodatkowe pluginy podepniesz do aplikacji zgodnie z w/w mechanizmami, czy jako DLL, albo może wrzucisz na stałe do kodu, a potem odpowiednio ukryjesz - tak czy siak musi być jakaś logika, która odpowiada za ustalenie, że dany klient ma mieć możliwość korzystania z danej funkcjonalności.

Nie logika, tylko licencja, która określa co jest dostępne i w efekcie co zostanie załadowane.
Jak logika i po co?
Widzisz, Ty chyba nie rozumiesz jak działa DI.

W jakiś sposób musisz to weryfikować.

Tak, weryfikuje licencję, czyli buduję mapę funkcjonalności, które dana licencja zawiera.

A to, jak to zostanie później zrealizowane - czy jak Ty proponujesz przez wstrzykiwanie, czy jakkolwiek inaczej - to jest kwestia wtórna.

Nie, to kwestia podstawowa.
Mi chodziło o pewne architektoniczne rozwiązania a nie skąd mam pobrać licencję...
Kwestią wtórną jest dla mnie czy licencja będzie na HASP, w pliku czy na serwerze licencji - to bez znaczenia i mało istotna sprawa.
Skądś dostaję strumień danych, który jest licencją.
Jakie ma to znaczenie skąd go odczytam?

A odnośnie IF/HASP - pisałem parę postów wyżej, że obecnie klucze HASP oferują znacznie więcej, niż samo sprawdzenie, czy klucz jest wsadzony w USB, obsługują m.in. szyfrowanie treści oraz dają możliwość osadzania części kodu w kluczu.

Czyli potrafią utrzymać zaszyfrowany strumień danych.
I co z tego?
Co to zmienia?
Ja rozumiem to tak, że to dalej tylko (bezpieczne?) medium dla danych wrażliwych.
Nic więcej i nic mniej.

Do tego producenci (chociażby podane przeze mnie linki) dostarczają bardzo fajną i obszerną dokumentację, łącznie z case study oraz poradnikami. Można tam znaleźć inspirację odnośnie tego, jak inaczej niż drabinka IF da się temat rozwiązać.

Nie, dziękuję, ale nie.
Po pierwsze i najważniejsze zastosowanie kluczy sprzętowych całkowicie nie przystaje do mojej filozofii licencjonowania oprogramowania.
Po drugie, większość dostawców ERP wycofała się z takiego zabezpieczania.
A po trzecie, tak naprawdę to ma małe znaczenie. Zabezpieczanie jakieś musi być, ale ma być bezobsługowe i bezkosztowe dla klienta końcowego. I nie przeceniałbym jakoś specjalnie jakości tego zabezpieczenia, a przynajmniej naprawdę - ja nie mam aż takich potrzeb.

nie trzeba robić weryfikacji. Trzeba zrobił ładowania pluginów, które zdefiniowano w licencji.

Z punktu widzenia zabezpieczenia przed piratami i nielegalnym korzystaniem z treści, wiele to nie zmienia. Jak ktoś będzie chciał to wymusi załadowanie innego plugina, podmieni licencję, zafałszuje komunikację z serwerem itp.

Powodzenia.
To samo mogę powiedzieć o kluczach sprzętowych, że "się da".

tylko licencja, która określa co jest dostępne

A czym u Ciebie jest ta mityczna licencja? Jaką ma postać?

cerrato napisał(a):

tylko licencja, która określa co jest dostępne

A czym u Ciebie jest ta mityczna licencja?

Zawiera informacje jednoznaczni identyfikujące klienta i zakres dostępnych dla niego funkcjonalności oraz liczbę dostępnych licencji dostępowych dla użytkowników końcowych.

Jaką ma postać?

Strumienia danych.
Jakie to ma znaczenie?

Czyli de facto dochodzimy do tego samego - i tak musisz pobrać jakąś licencję/klucz/cokolwiek, a następnie na jego podstawie ustalić, do jakich modułów/funkcji uzytkownik ma dostęp. Różnica jest taka, że mając wszystko wpisane "na sztywno" do EXE po prostu blokujesz dostęp do pewnych treści, natomiast w Twoim przypadku na podstawie treści licencji "wstrzykujesz" sobie odpowiednie moduły. Może i z punktu widzenia architektury robi to znaczącą różnicę, ale z punktu widzenia obsługi samego procesu licencjonowania - wychodzi praktycznie na to samo. Różnica jest taka, że w jednej opcji ukrywasz to, czego nie chcesz pokazać, a w drugiej ładujesz jedynie to, co ma być widoczne :P

cerrato napisał(a):

Różnica jest taka, że w jednej opcji ukrywasz to, czego nie chcesz pokazać, a w drugiej ładujesz jedynie to, co ma być widoczne :P

Jeżeli wg Ciebie nałożenie licencji polega na ukryciu buttonów/kontrolek, to tak jak piszesz.
Tylko z mojego punktu widzenia, wygląda to zupełnie inaczej.

Tylko z mojego punktu widzenia, wygląda to zupełnie inaczej.

Jakby Ci się chciało poświęcić trochę czasu oraz energii i to opisać (im więcej szczegółów tym lepiej) to ja (i pewnie kilka innych osób udzielających się w tym wątku) byłbym wdzięczny, chętnie poczytam :)