Ich hätte da mal eine Frage an diejenigen, die schon größere Projekte in Purebasic gemacht haben.
Es geht da um eine größere GUI-Business-Anwendung; mit etwa 200 inhaltlich komplexen, aber technisch eher einfachen Dialogen. Dazu kommt dann noch ein Framework für die Kommunikation, globale Prozeduren etc., schätzungsweise 200.000 lines of code. Wie würde man so etwas auf der Basis von PB organisieren, auch unter dem Gesichtspunkt der Parallelentwicklung, hat da jemand Erfahrungen?
Das scheint mir zu viel zu sein, um alles einfach per Include zusammenzubinden und jedes mal komplett neu zu kompilieren, oder? Wenn ja, wie organiere ich das dann? Alles in eigene Userlibs? Wechselseitiges Aufrufen aus Userlibs sollte doch gehen, oder? Oder DLLs? Und wie mache ich das dann mit den globalen Variablen? Ganz drauf verzichten? Oder per Struktur und globalem Memory? Hat vielleicht jemand einen Programmrahmen für so was?
Projektarchitektur
- NicTheQuick
- Ein Admin
- Beiträge: 8820
- Registriert: 29.08.2004 20:20
- Computerausstattung: Ryzen 7 5800X, 64 GB DDR4-3200
Ubuntu 24.04.2 LTS
GeForce RTX 3080 Ti - Wohnort: Saarbrücken
So wie sich das anhört, würde ich da gar nicht erst mit PB anfangen.
Falls es unbedingt in PB sein soll:
Benutz Interfaces und versuch OOP nachzubilden.
Nachdem ihr eurer Projekt dann schön mit Klassen- und Sequenzdiagrammen geplant habt,
sollte es sogar in PB funktionieren. Allerdings kann man da nicht so schön mit Vererbung
arbeiten, was mich an PB schon sehr stört.
Für OOP gibt es auch einen Precompiler von inc. aus dem englischen Forum. Ich weiß aber
nicht, in wie fern das schon 100% läuft.
Ein großes Problem wird auch die Teamarbeit werden, wenn ihr nicht einen Editor nutzt, der
SVN beherrscht.
Falls dir ein paar Abkürzungen noch nichts sagen, dann schau einfach mal in der Wikipedia
nach.
Falls es unbedingt in PB sein soll:
Benutz Interfaces und versuch OOP nachzubilden.
Nachdem ihr eurer Projekt dann schön mit Klassen- und Sequenzdiagrammen geplant habt,
sollte es sogar in PB funktionieren. Allerdings kann man da nicht so schön mit Vererbung
arbeiten, was mich an PB schon sehr stört.
Für OOP gibt es auch einen Precompiler von inc. aus dem englischen Forum. Ich weiß aber
nicht, in wie fern das schon 100% läuft.
Ein großes Problem wird auch die Teamarbeit werden, wenn ihr nicht einen Editor nutzt, der
SVN beherrscht.
Falls dir ein paar Abkürzungen noch nichts sagen, dann schau einfach mal in der Wikipedia
nach.
Es wäre auch noch interessant zu wissen, ob Du überhaupt schonmal an einem annähernd so großen Projekt gearbeitet hast, oder ob das eine Premiere werden soll und Du davor nur kleine 5000-Zeilen-Progrämmchen geschaffen hast. Gerade auch da Du fragst, wie Du das mit den globalen Variablen machen sollst, sieht es so aus, als könnte letzteres der Fall sein. Wenn ja, dann wären auf jeden Fall noch ein paar Infos notwendig, um Dir überhaupt irgendwie ein paar sinnvolle Ratschläge geben zu können.

ZeHa hat bisher kein Danke erhalten.
Klicke hier, wenn Du wissen möchtest, woran ihm das vorbeigeht.
Nick, mit OOP habe ich nicht viel am Hut. Businessdaten sind relational, nicht hierarchisch, ich habe noch nie verstanden, was OOP da bringen soll. Das System läuft derzeit in einer ganz supermodernen OOP-Sprache, designed von ganz hochprofessionellen Experten in einem ganz supermächtigen Editor, der all das kann, was du willst, 100 MB im Download Minimum (der Editor!), da hat das System übrigens >3x mehr LoC als vorher auf einer Legacy-Plattform, ist nur leider unwartbar, inperformant, fehleranfällig und – teuer. Da suchen wir jetzt nach einer etwas einfacheren und schlankeren Alternative für eine letztlich nicht allzu anspruchsvolle Datenbankpflege (OOP ist dabei allerdings nicht der entscheidende Punkt).
ZeHa, es geht nicht darum, was ich programmiermäßig kann oder nicht (ich bin nur der doofe Produktverantwortliche, der die Technik seinen Vendoren überlassen muss), sondern darum, ob man so etwas in PB machen kann (das Problem sehe ich durchaus), ob es dazu Konzepte, Erfahrungen, Hinweise gibt. Mich irritiert halt etwas, dass es in PB keine OBJs gibt, und da frage ich mich halt, wie man da dann so ein Projekt strukturiert. Ich habe mit PB eine kleine Demo gemacht, die den fetten Schinken in ziemlich jeder Hinsicht outperformt; da frage ich mich jetzt halt, ob so etwas tragfähig für das Ganze sein könnte.
Aber man hat mir schon offenbart, dass für PB keine Leute zu finden seien, weil ja jeder die fetten Schinken programmieren wollte – da verdient man nämlich mehr. Wenn man so was hört, kommt man schon ins Grübeln…
ZeHa, es geht nicht darum, was ich programmiermäßig kann oder nicht (ich bin nur der doofe Produktverantwortliche, der die Technik seinen Vendoren überlassen muss), sondern darum, ob man so etwas in PB machen kann (das Problem sehe ich durchaus), ob es dazu Konzepte, Erfahrungen, Hinweise gibt. Mich irritiert halt etwas, dass es in PB keine OBJs gibt, und da frage ich mich halt, wie man da dann so ein Projekt strukturiert. Ich habe mit PB eine kleine Demo gemacht, die den fetten Schinken in ziemlich jeder Hinsicht outperformt; da frage ich mich jetzt halt, ob so etwas tragfähig für das Ganze sein könnte.
Aber man hat mir schon offenbart, dass für PB keine Leute zu finden seien, weil ja jeder die fetten Schinken programmieren wollte – da verdient man nämlich mehr. Wenn man so was hört, kommt man schon ins Grübeln…
Hi Lupus.
Ich hoffe ich mache jetzt keine falschen Hoffnungen, aber ich denke sowas sollte mit PB funktionieren.
Ganz wichtig dabei ist, sich vorher viele ... sehr viele Gedanken zur Gesamtstruktur und damit zu den benötigten Ebenen und Daten zu machen. Damit man dann bei der Arbeit nicht das böse Erwachen hat *g*
Einzelnen Abschnitte würde ich in Includes bzw. DLLs kappseln. Bei einer ordentlichen Namensgebung sollte es dann kaum Probleme geben.
Ich selbst hab auch schon größere Projekte gemacht (20000 - 30000 Zeilen), und diese sind so klar strukturiert, dass es ein leichtes ist, da wieder einzusteigen und weiter zu arbeiten.
Daher biete ich Dir auch gerne meine Hilfe an. Sag' einfach bescheid, vielleicht kommt ja eine nette Zusammenarbeit bei raus ;o)
Gruss, Morty
Ich hoffe ich mache jetzt keine falschen Hoffnungen, aber ich denke sowas sollte mit PB funktionieren.
Ganz wichtig dabei ist, sich vorher viele ... sehr viele Gedanken zur Gesamtstruktur und damit zu den benötigten Ebenen und Daten zu machen. Damit man dann bei der Arbeit nicht das böse Erwachen hat *g*
Einzelnen Abschnitte würde ich in Includes bzw. DLLs kappseln. Bei einer ordentlichen Namensgebung sollte es dann kaum Probleme geben.
Ich selbst hab auch schon größere Projekte gemacht (20000 - 30000 Zeilen), und diese sind so klar strukturiert, dass es ein leichtes ist, da wieder einzusteigen und weiter zu arbeiten.
Daher biete ich Dir auch gerne meine Hilfe an. Sag' einfach bescheid, vielleicht kommt ja eine nette Zusammenarbeit bei raus ;o)
Gruss, Morty
Man kann aber auch hier schonmal drüber diskutieren, ob die Businessdaten in ihrer Form richtig angelegt sind, oder ob da Hierarchien nicht auch etwa sinnvoller wären. Es gibt ja z.B. auch Objektdatenbanken.Businessdaten sind relational, nicht hierarchisch, ich habe noch nie verstanden, was OOP da bringen soll.
Auf Deine bestehenden Daten bezogen ist es natürlich was anderes, denn diese sind ja schon relational und wenn die so bleiben sollen, dann ist Deine Frage natürlich durchaus berechtigt.
Was meinst Du jetzt mit OBJs? Meinst Du einfach Objekte, sprich, Objektorientiertheit? Wenn Dich das irritiert, dann wundert mich das jetzt aber schon auch wieder, denn oben sagst Du ja, daß Du es sowieso nicht OOP haben möchtest.Mich irritiert halt etwas, dass es in PB keine OBJs gibt, und da frage ich mich halt, wie man da dann so ein Projekt strukturiert.

ZeHa hat bisher kein Danke erhalten.
Klicke hier, wenn Du wissen möchtest, woran ihm das vorbeigeht.
Morty, danke für die Ermutigung, vielleicht komme ich auf dein Angebot zurück (wenn was draus wird).
ZeHa, das mit der Relationalität war grundsätzlich gemeint. Businessdaten haben im wesentlichen die Struktur Kunde - Produkt - Auftrag - Position usw.; da ist keines eine Spezialisierung (das Kind) des anderen, viel wesentlicher sind die relationalen Zusammenhänge. Das ist m.E. auch der Grund dafür, dass sich die kommerzielle Bedeutung von Objektdatenbanken auch in engen Grenzen hält.
Mit den OBJs meinte ich die *.obj-Dateien, den Input für den Linker, bei C und so.
ZeHa, das mit der Relationalität war grundsätzlich gemeint. Businessdaten haben im wesentlichen die Struktur Kunde - Produkt - Auftrag - Position usw.; da ist keines eine Spezialisierung (das Kind) des anderen, viel wesentlicher sind die relationalen Zusammenhänge. Das ist m.E. auch der Grund dafür, dass sich die kommerzielle Bedeutung von Objektdatenbanken auch in engen Grenzen hält.
Mit den OBJs meinte ich die *.obj-Dateien, den Input für den Linker, bei C und so.
ich denke ich kann das Problem von Lupus nachvollziehen.
In meiner Zividienststelle nutzt der Verwaltungsapparat (1 Angestellte + Chef) eine Software, die den benötigten Umfang ums n-fache übersteigt.
Die Folge: elendig langsam, andauernde ratlosigkeit der Bediener und extrem oft Probleme, die durch den, natürlich nicht kostenfreien, Fernwartungsdienst oder die Hotline gelöst werden müssen. Oft Fehler, für die die Benutzer mal nichts können.
Ich habe mir auch schonmal gedacht, warum nicht das ganze auf das, was man braucht, beschränken? Absolute Ressourcenverschwendung das ganze.
Und ja, ich denke das wäre in PB umsetzbar. Nicht einfach, aber machbar.
In meiner Zividienststelle nutzt der Verwaltungsapparat (1 Angestellte + Chef) eine Software, die den benötigten Umfang ums n-fache übersteigt.
Die Folge: elendig langsam, andauernde ratlosigkeit der Bediener und extrem oft Probleme, die durch den, natürlich nicht kostenfreien, Fernwartungsdienst oder die Hotline gelöst werden müssen. Oft Fehler, für die die Benutzer mal nichts können.
Ich habe mir auch schonmal gedacht, warum nicht das ganze auf das, was man braucht, beschränken? Absolute Ressourcenverschwendung das ganze.
Und ja, ich denke das wäre in PB umsetzbar. Nicht einfach, aber machbar.
pb 4.51
