mvc pattern, modul, grundsätzliche frage
1 0 0 
molily
0
mvc pattern, modul, grundsätzliche frage
Hallo,
eine kleine Grundsatzfrage zur Vorgehensweise in einem MVC-Framework:
ich habe mir ein kleines MVC-Framework gebastelt, welches URLs direkt auf Applikationen abbildet, ähnlicher Ansatz wie z.b. Django oder Symphony2.
example.com/company/jobs/show/343
würde zum Beispiel den Jobs mit der ID 343 zeigen.
die Verzeichnisstruktur wäre:
root
-apps
--company
---jobs
--someapp
---somesubapp
-core
--classes
Ich denke, dass muss ich nicht weiter erklären. Daneben gibt es noch einen Core, der bestimmt Klassen bereitstellt, die man immer mal wieder braucht, z.b. Validatoren, Streamparser, Builder, und so weiter. Sollte auch klar sein.
Nun möchte ich Modul (app) basteln, die mir das Anlegen und Bearbeiten eines Graphen erlaubt.
-apps
--graph
---nodes
---edges
example.com/graph/show/5 => zeigt gesamten graph an
example.com/graph/edges/32 => zeigt Kante 32 an
etc.
Soweit so gut. Nun die eigentliche Frage. Ich benötige diese Graphengeschichte NUR als Grundlage für ein paar weitere Applikationen, für sich wird die App "graph" nicht genutzt. Ist es sinnvoll, innerhalb dieser neuen Applikationen die Applikation "graph" zu nutzen, also eine Abhängigkeit von einer anderen Applikation zu schaffen, oder sollte die Basisfunktionalität für den Graphen (anlegen, durchwandern, berechnen) besser im Core abgebildet werden?
Argh, etwas unverständlich, aber ich hoffe, ihr wisst, was ich meine. Es ist nämlich so, dass ich nicht genau weiß, wo ich das unterbringen will. Einerseits ist mir der Graph zu speziell, um ihn im Core unterzubringen, andererseits zu grundlegend, um dafür eine App anzulegen, die für sich nie genutzt wird.
viele Grüße
Santander
-
Hallo,
ich habe mir ein kleines MVC-Framework gebastelt, welches URLs direkt auf Applikationen abbildet, ähnlicher Ansatz wie z.b. Django oder Symphony2.
example.com/company/jobs/show/343
die Verzeichnisstruktur wäre:
root
-apps
--company
---jobs
--someapp
---somesubapp
-core
--classesAlso irgendwie hat das alles was du hier aufzählst nix mit MVC zu tun, wo sind denn deine Models? Wo sind deine Views? Ich sehe hier nur controller.
Ich würde deinen Graphen ins lib Verzeichnis reintun, damit er von dem jeweiligen Controller benutzt werden kann. Ganz grob würde das bei mir in etwa so aussehen:
app
controller
company
models
company
job
views
company
lib
graph
base
model
controller
view/Jeena
-
Hi,
Also irgendwie hat das alles was du hier aufzählst nix mit MVC zu tun, wo sind denn deine Models? Wo sind deine Views? Ich sehe hier nur controller.
doch, hat es natürlich. Nur wollte ich nicht die gesamte Dateistruktur hier abbilden.
controller und models finden sich in der jeweiligen app (oder subapp)
apps
--jobs
---controller
---models
---helpersviews finden sich u.U. in
apps
-templates
--jobs
--defaultwie auch immer, ich glaube, ich muss meine Frage nochmal reformulieren. Vielleicht komme ich dann auch selbst auf ein passendes Ergebnis.
danke nochmal!
-
-
hi,
Argh, etwas unverständlich, aber ich hoffe, ihr wisst, was ich meine. Es ist nämlich so, dass ich nicht genau weiß, wo ich das unterbringen will. Einerseits ist mir der Graph zu speziell, um ihn im Core unterzubringen, andererseits zu grundlegend, um dafür eine App anzulegen, die für sich nie genutzt wird.
Eine Funktionalität, die nur selten genutzt wird in den Core? Nein, dann wird das ja jedesmal mit kompiliert, auch dann, wenn es nicht gebraucht wird. Lade den Code bei Bedarf aus dem Dateisystem und kompiliere den zur Laufzeit. Nutze das Decorator-Pattern, damit der nachgeladene Code weiß, zu welcher Klasse der gehört.
Gus
-
Hallo,
Eine Funktionalität, die nur selten genutzt wird in den Core? Nein, dann wird das ja jedesmal mit kompiliert, auch dann, wenn es nicht gebraucht wird. Lade den Code bei Bedarf aus dem Dateisystem und kompiliere den zur Laufzeit.
Ein Problem stellt das Laden nur da, wenn man keinen vernünftigen Application-Server hat, der Code einmal lädt und einmal kompiliert (ich gehe von einer JIT-kompilierten Sprache aus, bei einer AOT-kompilierten Sprache erübrigt sich das Kompilieren).
Ein vernünftiger Application-Server (oder zumindest ein Interpreter mit Bytecode-Cache) kann das bisschen Code (i.d.R. Klassendeklarationen) ruhig beim Startup laden und im Speicher vorhalten, anstatt zur Laufzeit Dateien von der tausendmal lahmeren Festplatte zu laden und ggf. den Code zu übersetzen.
Mathias
-
-
Meine Herren!
Argh, etwas unverständlich, aber ich hoffe, ihr wisst, was ich meine.
Nicht wirklich. Ein Graph ist eine Datenstruktur, wie etwa Listen, Bäume, Stacks oder Queues. Wo würdest du solche Datenstrukturen in deinem Projekt unterbringen? Die Datenstruktur sollte so abstrakt wie möglich gehalten werden und von der Ein- und Ausgabe-Logik völlig entkoppelt sein. Wenn du die Datenstruktur dann fertig hast, kannst du darauf aufbauend immer noch eine App schreiben, die einen Graphen visualisieren und/oder transformieren soll. Beschreibe doch mal die Geschäftslogik einer App, die auf einem Graphen aufbauen könnte, wo lägen die Vorteile und Nachteile, wenn die App auf der bloßen Datenstruktur bzw. auf der Graphen-App aufsetzen würde?
