Ich versuche es mal anders: Wo holt myClass den Namespace, den sie bei getNamespace() zurück gibt, her? Über eine Konfigurationsdatei? Vorher, ebenfalls per DI?...?
Ankündigung
Einklappen
Keine Ankündigung bisher.
MVC und vergleichbare und Applikations-Config
Einklappen
Neue Werbung 2019
Einklappen
X
-
Gast
-
Im einfachsten Fall machst Du eine Methode, die get_class ($this) zurückliefert. Kommt eben drauf an, wie Du Deine Namespaces im Konfigobjekt organisierst. Wie gesagt, ist nur ein Beispielvorschlag, könnte auch so aussehen:
PHP-Code:$conf = Configs::get(get_class ($mC) , '*');
[COLOR="#F5F5FF"]--[/COLOR]
[COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
„Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
[URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
[COLOR="#F5F5FF"]
--[/COLOR]
Kommentar
-
Gast
Achso - Meinst Du (jetzt konkret an diesem Bsp.), dass das, was jetzt $conf enthalten würde, wäre bezogen auf die Klasse von $mc wäre?
Kommentar
-
Sozusagen. Ein globales Konfig-Objekt, aus dem Du Teilbereiche namespace-abhängig auslesen kannst (als Zugriffsobjekt) und der jeweiligen Klasse/Objekt auf welchem Weg auch immer injizieren kannst. Das jedes Objekt in jedem Konfig-Setting beliebig rumfuhrwerken kann, finde ich etwas fragwürdig.[COLOR="#F5F5FF"]--[/COLOR]
[COLOR="Gray"][SIZE="6"][FONT="Georgia"][B]^^ O.O[/B][/FONT] [/SIZE]
„Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
[URL="http://www.php.de/javascript-ajax-und-mehr/107400-draggable-sorttable-setattribute.html#post788799"][B]Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“[/B][/URL][/COLOR]
[COLOR="#F5F5FF"]
--[/COLOR]
Kommentar
-
Gast
-
Hallo xm22,
wie oben schon angesprochen interpretierst du DI nicht korrekt. DI ist situativ und nicht global und es löst explizite Abhängigkeiten auf. Das bedeutet auch, dass du in definierten Elementen deiner Software auf eine Konfiguration zurückgreifst, die genau im gewünschten Fall in das Objekt injiziert wird.
Benötigt ein Action-Controller eine Konfiguration, wird diesem einfach die notwendige Konfiguration per Definition injiziert. Die Art der Konfiguration kannst du ja gerne Abstrahieren und eine Klasse schreiben, die Konfigurations-Attribute auf zurückliefert. Der Kern des Mechanismus ist jedoch, dass du eine Möglichkeit schaffst, Inhalte jedweder Art in ein Objekt injizieren zu können.
Üblicherweise werden im JAVA-Bereich die Business-Objekte (Beans) mit Spring-DI erzeugt und diese können dann auch der Präsentations-Schicht als Konfigurations-Element dienen. Controller selbst per DI zu erzeugen halte ich für nicht notwendig. Die beschriebene Vorgehensweise ermöglicht dir die Konfiguration dann zuzugreifen, wenn du sie benötigst, ohne die Konfiguration in allen Objekten (was ohnehin Blödfug ist) vorhalten zu müssen. Weiterhin ist es dann nicht notwendig, Namespaces oder andere Unterscheidungs-Merkmale einzuführen, denn das Konfigurations-Objekt ist dann immer eine eigene Instanz.Viele Grüße,
Dr.E.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design [B]before[/B] you start to write code!
2. Discuss and review it together with [B]experts[/B]!
3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
4. Write [I][B]clean and reusable[/B][/I] software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kommentar
-
Gast
Ich denke, ich habe es schon verstanden. Das Hinkefuß ist in meinen Augen, dass ich, wenn ich das stringent durchziehen will, für alle Objekte, die dafür in Frage kommen, eine Konfiguration wie z. B. im APF vorhalten muss, die enthält, was das Objekt benötigt.
Bei den zig Klassen, die ich da habe, ist mir das einfach zu aufwändig.
Kommentar
-
Hallo xm22,
du musst eben nicht eine Konfiguration für alles vorhalten. Auch das APF tut das nicht. Möchtest du in einem Modul A eine Konfiguration haben, dann greifst du in Modul A darauf zu und sonst nirgends. Umgekehrt formuliert ist es auch Blödsinn, dass die Konfiguration eines Moduls A im Modul B zugreifbar ist.
Dashalb würde ich den vorgeschlagenen Weg gehen und deine Services mit DI erzeugen um dort - und nur wo es auch benötigt wird - die richtige Konfiguration zu haben.Viele Grüße,
Dr.E.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design [B]before[/B] you start to write code!
2. Discuss and review it together with [B]experts[/B]!
3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
4. Write [I][B]clean and reusable[/B][/I] software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kommentar
-
Gast
Ich verstehe schon, was Du damit meinst. Aber zwei Punkte sprechen (zumindest für mich dagegen):
1. Will ich _eine_ zentrale Konfiguration für alles
2. Sind das meiste übergreifende Informationen (z. B. Pfade, Logging-Informationen, etc.)
So sieht meine Config im Moment aus:
PHP-Code:<?php
return array(
'output'=>array(
'encoding'=>'utf-8'
),
'env'=>array(
'timezone'=>'Europe/Berlin',
'frontend'=>array(
'mediaPath'=>'c:\xampp\a/frontend/htdocs/media'
)
),
'db'=>array(
'host'=>'localhost',
'username'=>'root',
'password'=>'',
'database'=>'a',
'collate'=>'utf8_unicode_ci',
'encoding'=>'utf8',
'dbms'=>'mysql',
'port'=>3306
),
'auth'=>array(
'passwordSalt'=>'Dwer23$R"?Fewtfs"',
'roles'=>array(
'anonymous'=>1
)
),
'language'=>array(
'list'=>array(
'de'=>2,
'en'=>1
),
),
'core'=>array(
'applicationId'=>'wewewwsa324324"$we',
'errorLevel'=>E_ALL|E_STRICT,
'displayErrors'=>false,
'sessionName'=>'br.com',
//mandatory when using ZN_Log
'log'=>array(
'INFO'=>array(
'writers'=>array(
'ZN_Log_Writer_FirePHP'=>array(
'file'=>dirname(__FILE__).'/../log/test.log',
'type'=>'info',
'format'=>"%1\$s [%2\$s]\r\n--------------------------------------------------------------------------------\r\n%3\$s\r\n--------------------------------------------------------------------------------\r\n\r\n"
)
)
),
'ERROR'=>array(
'writers'=>array(
'ZN_Log_Writer_Screen'=>array(
'file'=>'test.log',
'format'=>"%1\$s [%2\$s]\r\n--------------------------------------------------------------------------------\r\n%3\$s\r\n--------------------------------------------------------------------------------\r\n\r\n"
)
)
),
'CRITICAL'=>array(
'writers'=>array(
'ZN_Log_Writer_Screen'=>array(
'file'=>'test.log',
'format'=>"%1\$s [%2\$s]\r\n--------------------------------------------------------------------------------\r\n%3\$s\r\n--------------------------------------------------------------------------------\r\n\r\n"
)
)
)
)
)
);
Kommentar
-
Hallo xm22,
auf etwas stehen oder nicht ist die eine Sache, dein Vorgehen verletzt jedoch Paradigmen der objektorientierten Entwicklung wie z.B. spearation of concerns.
Ich bin ebenfalls ein Freund davon, wirklich zentrale Elemente auch in einem zentralen Container zu halten (beim APF ist das die Registry), jedoch sind DB-Zugangsdaten definitiv keine globale Konfiguration. Denn: innerhalb einer Applikation kann es auch mehrere davon geben und diese können wiederum von diversen Parametern (Modul A benutzt Connection A, ...) abhängig sein. Ebenso das Thema Authentifizierung. Dieses kann man - das APF beweist das mit dem UMGT-Modul - sehr schön entkoppeln (separation of concerns) und als Komponente nutzen. Jede Komponente bringt dabei ihr eigenes Set von Konfigurationen mit, das einem - wie oben beschrieben - globalen Schema folgt.Viele Grüße,
Dr.E.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design [B]before[/B] you start to write code!
2. Discuss and review it together with [B]experts[/B]!
3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
4. Write [I][B]clean and reusable[/B][/I] software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kommentar
-
Gast
Mmh... Ich muss mir das mal durch den Kopf gehen lassen..
auf etwas stehen oder nicht ist die eine Sache, dein Vorgehen verletzt jedoch Paradigmen der objektorientierten Entwicklung wie z.B. spearation of concerns.
EDIT: Was sagst Du dann zu der WEb-Config bei asp.net?
Kommentar
-
Ich persönlich arbeite bei der globalen Konfiguration mit dem Singleton-Pattern. Informationsquelle ist ein XML, das mehrere "configuration" Elemente besitzt. Die Singleton-Klasse wählt entsprchend die korrekte Konfiguration aus (z.B. debug, qa, release), liest die Daten aus und stellt sie zur Verfügung. Könnte man sicher auch anders lösen, aber da das für mich funktioniert habe ich derzeit keine Veranlassung da etwas dran zu ändern.
Kommentar
-
Hallo xm22,
Zitat von xm22 Beitrag anzeigenWie das APF das löst, das habe ich auch eine Zeit lang so praktiziert. Aber schon allein verschiedene Umgebungen mit verschiedenen Parametern zu handlen artet bei dezentraler Konfiguration aus.
Zitat von xm22 Beitrag anzeigenEDIT: Was sagst Du dann zu der WEb-Config bei asp.net?Viele Grüße,
Dr.E.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Think about software design [B]before[/B] you start to write code!
2. Discuss and review it together with [B]experts[/B]!
3. Choose [B]good[/B] tools (-> [URL="http://adventure-php-framework.org/Seite/088-Why-APF"]Adventure PHP Framework (APF)[/URL][URL="http://adventure-php-framework.org"][/URL])!
4. Write [I][B]clean and reusable[/B][/I] software only!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kommentar
-
Gast
Kommentar