bituniverse.com

[Slava]

mit Reflection erzeuge ich nur ein neur object und untersuche die parametern von methoden.
die methode selbst rufe ich mit call_user_function_array
die geschwindigkeit ist ziemlich akzeptabel.
0.00025 s ist meine meinung nach ziemlich gute leistung.
grob sieht es so aus

Code:

class BU_View{}//zum test   class BU_Action{   protected $view=false;   protected $model=false;   protected $request=false;   public function __construct($request=false,$model=false,$view=false)   {     $this->request=$request;     $this->model=$model;     if($view)     {       $this->view=$view;      }     else     {       $this->view=new BU_View;     }   }   public function indexAction() {}   public function preAction(){}   public function postAction(){}   public function onError(){} } ############# class MeineAction extends BU_Action{   public function __construct(){    parent::__construct();    echo 'constructor<br />';//     }   public function meinmethodAction($tid=1,$page=2)   {     echo 'meinmethodAction($tid='.$tid.',$page='.$page.')';   } } ###########   $s=microtime(true); function dispach($classname,$constructparam=array(),$method,$getparam){ $refobjct=new ReflectionClass($classname); $o=$refobjct->newInstanceArgs($constructparam); //$o=ReflectionClass::newInstance(array('Test','__construct'),array('constructor')); if(($o instanceof BU_Action)==false) die('die Objecte müssen BU_Action implementieren'); $o->preAction(); $action=new ReflectionMethod($classname,$method); if($action->isPublic() && substr(strtolower($action->getName()),-6)=='action') {  $parameter=$action->getParameters();  $parray=array();  foreach($parameter as $p)  {    if(isset($getparam[$p->getName()]))    {      $parray[]=$getparam[$p->getName()];    } else    {      $parray[]=$p->isOptional() ? $p->getDefaultValue(): '';    }      } }   call_user_func_array(array($o,$method),$parray); $o->postAction(); }   //dispach mit nur einem gesetztem parameter dispach('MeineAction',array(),'meinmethodAction',array('page'=>2));   echo microtime(true) - $s;

[Jens]

Zwei Anmerkungen dazu:

1) Das eine Modell pro Controller wirst Du nicht immer haben. Ich würde hier eher ein Registry-Pattern für vorschlagen.

2) Je mehr Methoden eine Action hat, desto größer ist die Zeit, die für die Reflection drauf geht. Wenn Du Dein Beispiel bei mir laufen lässt, dann erhälst Du für die Action folgende Zeiten (Mittelwerte):

0 Parameter - 0,00011s
2 Parameter - 0,00013s
5 Parameter - 0,00017s
7 Parameter - 0,000185s
10 Parameter - 0,00021s

Und alle diese Zahlen gelten für jeweils eine existente Methode. Setzt Du die Anzahl der bekannten Methoden hoch, dann steigt die Zeit pro Methode bei mir im Schnitt um 0,00003s.

Eine eigene Variante würde wahrscheinlich so bei 0,00035s landen, die aber konstant und relativ unabhängig von der Menge der Parameter und Actions.

Für uns bedeutet das, daß wir bei Verwendung der Reflection-API die Schnittstelle der Actions so klein wie irgendmöglich halten müssen, und die Anzahl der zu einem Zeitpunkt x im Speicher bekannten Methoden ebenfalls. Ansonsten summiert sich das ganz schnell.

Gruß Jens

[Simon W.]

Zum Einwand von dr.e., dass man mehrere Aktionen übergeben können müsste:
Letztendlich hat ja jede Aktion auch einen definierte End-Zustand, der angezeigt wird. Wenn genau dieser Zustand irgendwo gespeichert wird, weiß jeder Controller, was er tun muss, auch ohne dass eine 'neue' Aktion betätigt wurde. Der Benutzer macht ja immer nur eine Sache und demnach braucht auch bei jedem Seitenaufruf nicht mehr übertragen zu werden.
Oder meintest du das ganz anders?

[Slava]

so wie ich mir das vorstelle, wird pro ein url-aufruf nur eine einzelne KontrollerClasse geladen und nur eine einzelne actionsMethode aufgerufen. Ehrlich gesagt finde ich so eine performance voll in ordnung.
Zum Vergleich braucht ZendFramework für ein primitiver Controller aufruf etwa 0.05 sekunden
wenn wir nach der Registy und initialisierung von anderen relevanten Sachen in 0.001 bereich bleiben, dann sind wir in grünem bereich.
ich plane noch zusätzlich ein BoxDispatcher, der ermöglicht durch setzen von parameter beliebige Controllers und actionen aufrufen, und zwar so, dass man direkt eine Ausgabe von genzem als string bekommt. Das muss die Problematik von Plugins abdecken. Das wird zwar auch die performance ein wenig belasten, aber für die meiste Anwendungen muss das ausreichen.
für die Jenige, die 200 Seitenaufrufe pro Sekunde erweitern, machen wir ein Angebot und programmieren es mit C

[dr.e.]

Hallo Slava,

Zitat:

ja klar, dass die Datenschicht in Model verlagert wird, da es unsinnig wäre wenn die Leute, die Admin-teil entwickeln die gleiche gedanken über die gleiche querys bei einem anderem Kontroller machen müssten. Model will ich nicht wie bei CakePHP an Controller zwingend binden un werde mich besser auf die globale Model freuen.

Das wiederspricht sich aber trotzdem noch. Model != Datenschicht

Zitat:

die parameter, die in luft hängen können immer noch von Request->getParam('parametername') bzw wie bei ZendFramework über Segement geholt werden.

Diese Vorgehensweise ist nicht ganz einheitlich. Du hängst Parameter an die Actiondefinition und bietest auch die Möglichkeit diese aus der URL zu ziehen. Das bereitet IMHO Probleme bei der Ausführung einer Action, da nie klar ist, wie ein Parameter gehandelt , bzw. definiert werden muss.

Zitat:

wie gesagt, es werden auch defaultwerte, indexAction, als auch indexController vorgesehen. wenn bei einer url was fehlt, dann wird es bei jeder Anwendung problematisch sein.

Das beantwortet aber nicht die Forderung nach der Möglichkeit, mehrere Actions pro URL haben zu können, damit Abhängigkeiten von unabhängigen Modulen nicht aufgelöst werden müssen. das ist ein sehr wichtiger Punkt, denn wenn du schon Programmieraufgaben verteilst, muss das vom Grundfgerüst bereits unterstützt werden.

Zitat:

Ich will nicht noch eine zusätzliche Business-Komponente machen, da die zerteilung von einem Script in Model, Controller und View ist meine Meinung nach ausreichend (wenigstens für eine Mittelgrosse Software). der Controller muss nicht unbedingt arbeitslos bleiben

Falsch! Du wirst sogar gezwungen sein das zu tun, denn wenn es unterschiedliche ActionController gibt, die unterschiedliches tun und von unterschiedlichen Leuten programmiert werden, müssen diese eine API, bzw. gemeinsame Service-Schicht haben um ihre benötigten Daten zu beziehen. Sonst läufst du gefahr, dass jeder irgendwie in seinem Controller auf die Datenbank geht.

Ich könne noch mehr Themen kommentieren, spare mir das aber, denn es lässt sich auf zwei Feststellungen reduzieren:

1. Die Anforderungen wurden noch nicht sauber definiert. Es wird immer von "erst mal einfach" gesprochen, in anderen Diskussionen malt man sich aber komplexe Dinge wie Usermanagement aus, ohne drüber nachzudenken, ob das mit dem "Einfach-Ansatz" noch realisierbar ist.

2. Die Funktion bzw. die Intension eines Frameworks wurde im Rahmen der hier besprochenen Entwicklungsaufgabe nicht ehrlich und sauber betrachtet, sondern wegen des bereits angesprochenen "Einfach-Ansatz"es von vornerein verworfen, da es "zu schwer" ist sich einzuarbeiten. Viel schwerer ist es aber meines Erachtens ein Framework zu entwickeln - und danach sieht es hier zweifelsfrei aus - dann dieses zu testen, zu dokumentieren und dann zur Verfügung zu stellen. Das passt einfach nicht!

_________________

Grüße,
Dr.E.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have a look at www.adventure-php-framework.org!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[dr.e.]

Simon W. hat Folgendes geschrieben:

Zum Einwand von dr.e., dass man mehrere Aktionen übergeben können müsste: Letztendlich hat ja jede Aktion auch einen definierte End-Zustand, der angezeigt wird. Wenn genau dieser Zustand irgendwo gespeichert wird, weiß jeder Controller, was er tun muss, auch ohne dass eine 'neue' Aktion betätigt wurde. Der Benutzer macht ja immer nur eine Sache und demnach braucht auch bei jedem Seitenaufruf nicht mehr übertragen zu werden. Oder meintest du das ganz anders?

Das sind interne Abläufe eines jeden Controllers, was du beschreibst. Es geht aber um die Gesamt-Architektur, die - falls modular aufgebaut - nur dann funktioniert, wenn Abhängigkeiten aufgelöst werden können. Das bedeutet, dass Module unabhängig voneinander existieren können müssen und es ebenso möglich sein muss, dass Model-Informationen (=Zustand eines einzelnen Moduls) über mehrere Requests gehalten werden kann. Mein Beispiel war die Navigation innerhalb einer Newsbox, die auf einer speziellen Unterseite eingebunden ist. Navigiert man in dieser Newsbox auf eine andere Seite, so sollte man immer noch auf der Unterseite bleiben. Wenn - und so muss es möglich sein - diese beiden Controller nun die benötigten Informationen haben, ist das kein Problem, fehlen diese, landest du auf der Startseite und der richtigen News-Box-Unterseite, oder auf der selbigen Seite, aber immer noch auf der identischen News-Box-Unterseite. Jetzt könnte einer sagen, dass ihn das nicht interessiert, da er im SeitenController einfach die Abhängigkeiten der Newsbox aufnimmt und dann geht das. Richtig, nur ist das bei n Modulen einfach nicht mehr machbar. Aus diesem grund muss es gerade in FrontController-basierten Applikationen - und Slava implementiert einen FrontController - Model-Informationen mehrerer Module über mehrere Requests zu vermitteln.

Konkret bedeutet das, dass die Zustandsinformationen (=Model) der kompletten Applikation - zusammengesetzt aus mehreren Modulen - in der URL dynamisch abbildbar sein müssen. Das bisherige Layout und auch das Layout des Zend Frameworks bilden das beispielsweise nicht ab. Dort ist man gezwungen Abhängigkeiten intern aufzulösen, was extrem aufwändig und für modulare Software nicht brauchbar ist.

Ich hoffe damit wird es etwas klarer.

_________________

Grüße,
Dr.E.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have a look at www.adventure-php-framework.org!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[dr.e.]

Hallo Slava,

Slava hat Folgendes geschrieben:

so wie ich mir das vorstelle, wird pro ein url-aufruf nur eine einzelne KontrollerClasse geladen und nur eine einzelne actionsMethode aufgerufen. Ehrlich gesagt finde ich so eine performance voll in ordnung. Zum Vergleich braucht ZendFramework für ein primitiver Controller aufruf etwa 0.05 sekunden

Hier wird Performance mit Funktion vermengt und das ist nicht gut. Dass das Zend Framework nicht gerade das schnellste ist liegt in der Architektur begraben, man sollte aber gerade meinen vorherigen Beitrag beachten. Diese Baustelle würde ich mir an deiner Stelle nicht antun wollen.

Zitat:

ich plane noch zusätzlich ein BoxDispatcher, der ermöglicht durch setzen von parameter beliebige Controllers und actionen aufrufen, und zwar so, dass man direkt eine Ausgabe von genzem als string bekommt.Das muss die Problematik von Plugins abdecken. Das wird zwar auch die performance ein wenig belasten, aber für die meiste Anwendungen muss das ausreichen.

Das halte ich für einen Fehler. Wenn du schon mit Generik anfängst, solltest du das so implementieren, dass das grundsätzlich innerhalb der Applikation möglich ist. Strings zwischen Modulen hin und her zu schaufeln ist nicht zielführend. Wichtiger ist es einen Rahmen zu schaffen, der die Module sauber aufnimmt und es sollte ein globales Model, eine Business- und datenschicht existieren, die eine Basis für Module bieten.

_________________

Grüße,
Dr.E.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have a look at www.adventure-php-framework.org!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[Slava]

dr.e.
jetzt bin ich echt überfördert und würde am bestens alles wegschmeissen.
Ich gebe dir bei vielen Punkten Recht, besonders was die eigene Entwicklung von Framework betrifft.
Jetzt möchte ich dich bitten, dass du mir die Vorgehensweise und realisteische Einsätze erklärst bei der Aussage:
"Wichtiger ist es einen Rahmen zu schaffen, der die Module sauber aufnimmt und es sollte ein globales Model, eine Business- und datenschicht existieren, die eine Basis für Module bieten."
Welche Einsatz würdest du vorschlagen um saubere Modulaufname zu realisieren.
Das interessiert mich sehr, welche Einsätze in diese Richtung führen können.
Ich will aber ehrlich sagen, dass ich mit mehreren Begriffen, die Du aufgelistet hast nicht zur recht komme.
Ich verstehe nicht ganz was du an Business-schicht und datenschicht klasifizierst und verstehe nicht ganz welche Unterschied zwischen Model im sinne MVC zu Datenschicht gibt.
Ich verstehe auch nicht ganz was an der von mir vorgeschlagener BoxDispatcher falsch ist, denn gerade er muss es erlauben mehrere Controller samt ihrer Ausgabe an output zu bekommen.
Ich will eigentlich einige massen verständliche zerteilung machen, die an hand von einer url einem entwickler eine Möglichkeit bietet an passende code zu gelangen und die code selbst auch von Layoutkram trennen.
Werde ich noch mehr 'ginerischen' schichten darauf legen, wird kein mensch mehr in stande der Konzept ohne detailirten verständinis von MVC.driver verstehen und auch die code wird sehr stark von einanderen gehen, was die Vorteile bei der Suche auf die richtige codestück wegen sehr starker Code-Verteilung zu nichte macht.
Ich weis auch nicht, was dagegen spricht, wenn ich in einer actionsmethode nicht nur über methodenparameter, sondern zusätzlich ein zugrif auf die künstiliche-getparameter erlaube, die in dem object Request zu finden sind. Das zwingt doch keinen Sie zu benutzen, besonders wenn man sie als Methodenparameter mit defaultwerten beschreibt.

[dr.e.]

Hallo Slava,

sorry, wenn ich zwischen durch auf "traditional chinese" gewechselt bin, ich will dir meine Ansätze und Erfahrungen gerne erklären:

Zitat:

"Wichtiger ist es einen Rahmen zu schaffen, der die Module sauber aufnimmt und es sollte ein globales Model, eine Business- und datenschicht existieren, die eine Basis für Module bieten." Welche Einsatz würdest du vorschlagen um saubere Modulaufname zu realisieren. Das interessiert mich sehr, welche Einsätze in diese Richtung führen können.

Du hast ja im Verlauf des Threads mehrere Ansätze besprochen, die es ermöglichen sollen modular zu programmieren. Was aber fehlt ist ein echtes Modul-Management. Dieses kannst du zwar via URL-Layout ansatzweise generieren, wie sieht es jedoch mit der Einbindung von GUI-Elementen (=Modulen) aus globaler Sicht aus? Wie kann ich beispielsweise ein Gästebuch schreiben und dieses dann in deine Applikation einbinden? Diese Fragen müssen meiner Meinung nach geklärt werden, ehe ich mir über ein Thema wie UserManagement Gedanken mache. Einfach ausgedrückt: ein Modul-Konzept muss auf allen Ebenen greifen.
Weiterhin ist bei einer modularen Applikation interessant, welche Gemeinsamkeiten die Module haben. Nehmen wir ein Forum, so könnte man die "Übersicht der Topics", die "Listen-Ansicht eines Topics" und die "Verfassen-Ansicht" als jeweils ein Modul bezeichnen. Diese Module haben sicher Gemeinsamkeiten wie Benutzung des UserManagements, oder andere globale Funktionen. Diese global genutzten Funktionen müssen - wenn man eine Applikation sauber entwirft - ausgelagert und in eigene Komponenten verpackt werden. Im Rahmen des 3-Schicht-Architektur-Pattern trennt man Logik die der Präsentation der Applikation dient (Präsentationsschicht; MVC ist ein Präsentationsschicht-Pattern), die Geschäftslogik (Workflows, ...) und die Datenlogik. Diese Schichten bieten der nächsthöheren oder unteren Schicht eine definierte API mit der diese kommunizieren kann. Inhalt bzw. Aufgabe der Business-Schicht (biz) ist es, alle für die Applikation relevante Informationen und Verhalten zur Verfügung zu stellen. Zu diesem Zweck hat die Business-Schicht die Datenschicht und das Model der Anwendung zur Verfügung. Die Datenschicht stellt persistente Daten zur Verfügung, das Model Laufzeitinformationen. Wie das in der Implemetierung genau aussieht, habe ich in einem Tutorial unter www.adventure-php-framework.org beschrieben. Ich hoffe das wird nun ein wenig klarer. Wichtig dabei ist zu verstehen, dass MVC zwar überall als das Pattern deklariert wird, jedoch im Gesamtdesign einer Software nur eine kleine Rolle spielt und mit mehreren anderen Mechanismen verwoben werden muss, damit es effizient eingesetzt werden kann.
Ich kann gerne nochmal ein konkretes Beispiel für eure Applikation machen, das UserManagement ist aber ein sehr gutes Beispiel, da isch behaupte, dass ein getUserByID() in fast jedem Modul eines Forums von Bedeutung ist.

Zitat:

Ich will aber ehrlich sagen, dass ich mit mehreren Begriffen, die Du aufgelistet hast nicht zur recht komme. Ich verstehe nicht ganz was du an Business-schicht und datenschicht klasifizierst und verstehe nicht ganz welche Unterschied zwischen Model im sinne MVC zu Datenschicht gibt.

Das Model im MVC-Paradigma ist eigentlich nicht ein Datenobjekt, wie es jedoch in vielen Literaturstellen steht. Ein Model beinhaltet Informationen, die zur Laufzeit zur Ausführung der Applikation benötigt werden. Nehmen wir das Beispiel Login, dann wird im Model der Applikation stehen, welcher Benutzer gerade eingeloggt ist, welcher View angezeigt werden soll, welche Aktionen der Benutzer bereits getätigt hat - wenn eine Funktion wie "Rückgängig" angeboten werden soll - und so weiter. Persistente Daten an sich werden nicht im Model gehalten oder von diesem bezogen, sondern dafür muss die Business-Schicht eine geeignete Methode bereitstellen, die dir mit Hilfe der Model-Informationen Daten bereitstellt. Das kann bei der Mitgliederliste des Forums wie folgt passieren:

Code:

class MemberController extends baseActionController {    function listAction(){         $Manager = new ForumManager();       $List =$ForumManager->getUserList();         // ... Code zur Darstellung ...      } }

Möchte man z.B. das Profil des eingeloggten Benutzers darstellen, so würde man soetwas schreiben:

Code:

class ProfileController extends baseActionController {    function displayAction(){         $Manager = new ForumManager();       $UserID = $Model->getUserID();       $User =$ForumManager->getUserByID($UserID);         // ... Code zur Darstellung ...      } }

Zitat:

Ich verstehe auch nicht ganz was an der von mir vorgeschlagener BoxDispatcher falsch ist, denn gerade er muss es erlauben mehrere Controller samt ihrer Ausgabe an output zu bekommen.

Falsch ist daran zunächst nichts, ich halte diesen Ansatz jedoch für nicht weitreichend genug. Er gibt dir zum einen die Möglichkeit abhängige Controller oder Actions aufzurufen, zum anderen gibt er dir einen Output zurück. Das wiederum ermöglicht aber nur ein sehr eingeschränktes GUI-Modell, da man einen Controller dann "nur" dazu verwenden kann eine Ausgabe eines Moduls zu erzeugen und dieses in einem anderen Controller zu verwenden. Das bedeutet dann auch, dass dieser eine Controller z.B. sämtliche andere Controller die den HTML-Code der kompletten Seite erzeugen aufrufen und die Ausgaben entsprechend an die Views geben muss. Somit baust du dir aber wieder Abhängigkeiten zum kompletten Satz an Modulen und/oder PlugIns, die du innerhalb der Applikation hast. Zudem musst du dann wieder alle möglchen Parameter aller möglichen Module, die du dort verwendest kennen. An dieser Stelle wäre natürlich angebracht, dass du nur mit dem Konstrukt

Code:

$Request->getParam('parametername')

arbeitest, dann entschärft sich das ein wenig. Was sich jedoch nicht entschärft ist, dass du die Möglichkeit vorsehen musst, dass mehrere Actions über die URL angesprochen werden.

Zitat:

Ich will eigentlich einige massen verständliche zerteilung machen, die an hand von einer url einem entwickler eine Möglichkeit bietet an passende code zu gelangen und die code selbst auch von Layoutkram trennen.

Das mag ja für eine kleine Anwendung reichen, die Realität eines Projektes, die ihr hier vorhabt, wird sicher komplexer und damit hässlicher sein. Sorry, aber die Wahrheit ist meistens grausam...

Zitat:

Werde ich noch mehr 'ginerischen' schichten darauf legen, wird kein mensch mehr in stande der Konzept ohne detailirten verständinis von MVC.driver verstehen und auch die code wird sehr stark von einanderen gehen, was die Vorteile bei der Suche auf die richtige codestück wegen sehr starker Code-Verteilung zu nichte macht.

Ein sehr weiser Designer sagte mir einmal: ein komplexes System kann nie einfach sein. Das gilt auch hier. Wenn man Aufgaben verteilen möchte, muss man an beiden Seiten der Straße Leitplanken haben, die dem Entwickler vorgeben, wie sein Bereich aussehen soll. Das sind

- Anforderungen an die Funktionen
- Allgemeine Software-Design-Richtlinien (Coding-Conventions eines Frameworks oder hier eines
MVC-Drivers plus Front Controller)
- Basis-Software (Business-Schicht + Daten-Schicht)

Mit diesen drei Grundlagen, kann dieser dann arbeiten und ein Modul (Controller mit Actions) bauen.

Zitat:

Ich weis auch nicht, was dagegen spricht, wenn ich in einer actionsmethode nicht nur über methodenparameter, sondern zusätzlich ein zugrif auf die künstiliche-getparameter erlaube, die in dem object Request zu finden sind. Das zwingt doch keinen Sie zu benutzen, besonders wenn man sie als Methodenparameter mit defaultwerten beschreibt.

Wie oben bereits erläutert nimmst du dir die Generik, wenn du Parameter in Action-Methoden direkt deklarierst, weil du dann sehr stark an die Semantik der URL gebunden bist. CakePHP erzeugt beispielsweise URLs der Form

Code:

/controller/action/value1/value2/...

und ist damit nicht flexibel, was die Anordnung der Parameter in der URL ist. Mit anderen Worten: ich würde mich nicht schon von Beginn an einschränken, wenn ich genau weiß, dass das schief gehen kann oder Einschränkungen mit sich bringt.

_________________

Grüße,
Dr.E.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have a look at www.adventure-php-framework.org!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[dr.e.]

Hallo zusammen,

da auf diesen Thread keine Antwort mehr kam, möchte ich nochmal bekräftigen, dass ich keinen verschrecken wollte, ich möchte nur aufzeigen, welche Herausforderungen bei der Entwicklung eines solchen Projektes entstehen können. Da ich derartige Projekte zur Genüge kenne, hielte ich es für notwendig meine Bedenken mitzuteilen.

_________________

Grüße,
Dr.E.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have a look at www.adventure-php-framework.org!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~