Controller - co lepsze?, getInstance(), czy przekazywanie obiektom... Opcje

[Prph]

Witam,

Co jest lepszym rozwiazaniem? Singletone, czy przekazywanie go obiektom?
Dla przykladu:

[PHP] pobierz, plaintext 
<?php
// 1 rozwiazanie, klasa akcji:
 
public function execute(IController $oController)
{
  $oController->.......;
}
 
// 2 rozwiazanie, klasa akcji:
 
public function execute()
{
  $oController = Controller::getInstance();
  $oController->.......;
}
?>
[PHP] pobierz, plaintext 

Adrian.

[Ludvik]

Lepiej przekazywać jako argument funkcji. Pytanie tylko - po co przekazywać obiekt kontrolera akcjom? Nigdy nie spotkałem się z taką potrzebą, dlatego mnie to dziwi.

[Prph]

Dlaczego? Zobacz Mojavi - tam wszedzie sie tak robi.
Dlaczego Akcjom? Kontroler jest otoczka dla calej aplikacji. Kontroler udostepnia kontekst, ten zas request.

Siadam do kodu, jednak zmienie na singletone. dotychczas caly framework mial zorganizowany na zasadzie przekazywania kontrolera obiektom. Ale zauwazylem, ze moze to powodowac bledy - chociazby typu referencja, kopia obiektu. Oczywistym jest ze powinny byc to wszedzie referencje.

Adrian.

[anas]

Hej.

Wydaje mi się że dużo lepiej jest przekazywać obiekt w konstruktorze po typie to daje możliwość podmiany implementacji danego interfejsu na inny - czyli jednym słowem zwiększa elastyczność kodu. Pracowanie na instancji tworzonej wewnątrz innej klasy powoduje że wymuszasz konkretny typ i w razie potrzeby modyfikować już istniejący kod - a nie o to chodzi w OOP.

Pozdrówka

anas

[Prph]

Z drugiej strony czesc obiektow otrzymuje w kontruktorze kontroler i nalezy sie do niego odwolac przez powiedzmy $this->_getController();. Czesc natomiast dostaje w wywolaniu metody execute().
Z nowu nie zawsze potrzebuje tego kontrolera, a jednak jest przekazywany w funkcji.

Najbardziej denerwuje mnie ta roznica w przekazywaniu w kontruktorze albo w execute();

No i na sam koniec - framework ma byc dla mnie maksymalnie wygodny.

[orson]

witam

Jestem w trakcie kończenia innego rozwiązania. Jest klasa która jest managerem instancji ... zwraca obiekt wg jego nazwy oraz nazwy instancji (nazwa nie jest wymagana - może być utworzona automatycznie dla singletona - wtedy wiadomo że nie trzeba znać instancji, wystarczy nazwa klasy) ... może automatycznie tworzyć singletony (oczywiście jak ktoś z palca wywoła klasę która ma publiczny interfejs to dostanie obiekt ) lub nie pozwalać by dana klasa była używana jako taki ( za każdym razem zwraca nową instancję) ... po ustawieniu dodatkowych pól wewnątrz klasy (nie są wymagane) klasa tworzona może współpracować z managerem ... użycie odbywa się na zasadzie:

[PHP] pobierz, plaintext 
<?php
$obj = aeClassManager::getInstance('someSingletonClass', 'instanceName', true, array('param'=>'value'));
$obj2 = aeClassManager::getInstance(array('someSingletonClass', 'methodToGetSingletonInstance'), 'instanceName', true, array('param'=>'value'));
?>
[PHP] pobierz, plaintext 

ten manager nie jest związany z jakąś szczególną klasą ale może być pomocny przy dużej ilości obiektów (duża aplikacja intranetowa - w tym celu go opracowuje) ...

jeżeli uda mi się dziś skończyć to udostępnie w dziale gotowe skrypty może się komuś przyda ...

pozdrawiam

[Ludvik]

Skoro tak musisz robić, to bym się skłaniał do przekazywania albo przez konstruktor albo przy wywołaniu samej akcji. Którą metodę wybierzesz, to zależy od Ciebie.

Z drugiej strony jak dla mnie, to strasznie skomplikowany jest kontroler w mojavi. Nie prościej wyodrębnić wszystkie dane kontekstu do osobnego obiektu?

[Prph]

Owszem, kontroler Mojavi ma troche skomplikowanego kodu
Dlatego ja piszac wlasny framework sporo usunalem. Rozwiazanie z Mojavi ma jedna zalete, ktora mi sie podoba - kontroler jest sercem calej aplikacji. To jak skrzyzowanie z ktorego mozna pojechac w kazde miejsce.

Dodalem jeszcze metody zwracania loggera oraz bazy danych.

Adrian.

[anas]

@orson: czy Twoje rozwiazanie to cos na zasadzie IoC? Jeśli tak to chętnie bym popatrzył jak rozwiązałeś przechowywanie relacji między obiektami. Jeśli nie to i tak ciekawi mnie Twoje podejście, czekam na skrypcik.

pozdrówka

anas

[orson]

witam

Niestety nie jest to IoC :/ może kiedyś
Zapraszam do zapoznania się z kodem:
Temat: klasa Instance Manager zarzadzanie instacjami obiektow

pozdrawiam

[bigZbig]

@orson - byłbym wdzięczny gdybyś przedstawił mi zalety używania Twojego menagera do pobierania obiektu singletona w stosunku do zwykłego getInstance

-- edit --

@Prph - a nie powinno byc na odwrot, ze to akcje przekazuje sie do kontrolera, a nie kontroler do akcji?

Ten post edytował bigZbig 3.07.2006, 10:49:43

[Ludvik]

Podpisuję się pod drugim pytaniem bigZbiga. W ten sposób tworzysz zbędne zależności pomiędzy akcjami a kontrolerem, kiedy akcja potrzebuje tylko dane z kontekstu, który można przekazać jako argument. Sam stosuję taką logikę i jakoś nigdy nie trafiłem na sytuację, która by wymagała zmiany mojego podejścia.

Ten post edytował Ludvik 3.07.2006, 11:12:23

[Cysiaczek]

W zasadzie, to ja też chciałbym przeczytac opinie na temat "kto komu i co powinien przekazywac w tym ukladzie"

[orson]

witam

@bigZbig: to jest rozwiązanie generalne. Pozwala ujednolicić sposób pobierania wszystkich obiektów ... nie tylko do singletownów ... nieraz wewnątrz metody musisz się odwołać do dblayera który nie może być singletonem (2 połączenia do 2 różnych baz w aplikacji) i zawsze chcesz dostawać określony obiekt ... podajesz nazwę klasy i instancję i zawsze dostaniesz ten sam obiekt co poprzednio ...

pozdrawiam

[anas]

Hej.

Również uważam, że bez sensu jest tworzyć sztywne powiązania między obiektami - lepszym i dającym większe pole manewru jest rozwiązanie pozwalające bez ingerencji w już stworzony kod, manipulować istniejącymi obiektami. Właśnie dlatego pytałem o IoC. Generalnie ciekawym podejściem jest AOP - czyli programowanie aspektowe. Pokrótce chodzi o to aby do już istniejąycych obiektów, bez ingerencji w kod dorzucać nową funkcjonalność, podmieniać, wykonywać coś przed wywołaniem, lub po wywołaniu metody itd.

Przykład zastosowania:

Mamy sklep internetowy - wyliczamy cenę na podstawie kilku obiektów - cena bazowa -> podatek -> waluta = cena za produkt. Załóżmy że klient stwierdza po 3 miesiącach że chciałbym na wybrane produkty dorzucać promocję. Wtedy dzieki możliwości zdefiniowania funkcjonalności która wykona się ma obiekcie product, np.

$product->getProductPrice(Tax $taxObject, Currency $currencyObject, ProductDAO $productDAO);

zaraz po zwróceniu przez powyższą metodę wartości -> (Invoke.AfterReturning - definiuje kiedy ma sie wykonac nowa funkcjonalnosc). Po tym wszystkim należałoby zdefiniować dla jakich metod ma się to wykonać - np. Include("getProductPrice*") i mamy powiazania - tym wszystkim musi zarzadzac specjalnie przygotowane narzedzie.

W chwili obecnej w php ze wgzledu na trudna implementacje nie spotkalem sie z takim czyms - ale to ciekawy pomysl, ktory warto by bylo poruszyc w przyszlosci - to daje naprawde ogromne mozliwosci manipulowania kodem, bez koniecznosci ingerowania w juz istniejacy. Co myślicie o takim podejściu?

pozdrawiam

anas

Ten post edytował anas 3.07.2006, 11:50:40

[NuLL]

Co myślicie o takim podejściu?

Podejscie fajne, ale raczej jestesmy bez szans jesli chodzi o implementacje w php. Musialbylo by to chyba dosc absudarlnie wygladac gdyz trzeba by jakoby sprawdzac kazde operacje co spowoduje narzut kodu wiekszy niz to wszystko warte.

Wracajac do tematu - przekazyc kontroler do akcji. To tak jakby umieszczac generala w oddziale, dac Kalacha to reki i kazac walczyc, a on ma przeciez dowodzic

Ten post edytował NuLL 3.07.2006, 11:58:04

[Cysiaczek]

Wydaje mi się, że samo przekazanie obiektu kontrolera nie jest złe, bo w sumie chodzi o to, aby zbudowac aplikacje na kontrolerze. Z drugiej strony ciekwaszym i bardziej elastycznym rozwiązaniem będzie utworzenie klasy bramy udostępniającej obiekt kontrolera.

w teorii
user_code --> interface (obiekt lub statycznie) --> controller

Oczywiście można stworzy taki interfejs bezpośrednio w klasie, ale byłoby to zbytnie sprzęganie.
Wilk syty i owca cała. W każdym razie tak mi się wydaje.

W drugim przypadku (przekazywanie akcji kontrolerowi) możemy napotkac w dalszej perspektywie pewne trudne do przewidzenia problemy związane z budową samej akcji, która musi by zbudowana tak, aby rozumiała kontroler i była podatna na testowanie.

Ehh. To podobnie jak z prawami użytkowników - trzymac je razem z uzytkownikiem, czy w jakimś centralnym miejscu...a moze jeszcze inaczej.

[bigZbig]

Myślę, że tu jest generalnie problem z nazewnictwem bo kontroler u Prph'a jest jak podejrzewam specyficznym obiektem typu DTO (Data Transfer Object) służącym jedynie do transportowania informacji.

@orson - poczytaj na temat rejestru obiektów w Zend Frameworku. Moim zdaniem chyba chcesz przekombinować swojego menadżera.

Ten post edytował bigZbig 4.07.2006, 07:20:27

[Prph]

@Prph - a nie powinno byc na odwrot, ze to akcje przekazuje sie do kontrolera, a nie kontroler do akcji?

To zalezy jak napiszesz framework.

Moj kontroller przypomina nieco kontroler Mojavi. Stanowi on "otoczke" calej aplikacji. Kontroler wykonuje akcjie. Te natomiast potrzebuja dostepu do danych post i get trzymanych w Kontekscie. A to kontroler posiada ow kontekst.

Jest to calkiem dobre rozwiazanie - wygodne. Wszystko co potrzebujesz jest w kontrolerze.

Adrian.

[NuLL]

Prosty quiz

[PHP] pobierz, plaintext 
<?php
 
class user
{
	private static $oInstance=null;
 
	private $id=0,$lang='';
 
	public static function getInstance()
	{
		if(self::$oInstance==null) self::$oInstance=&new user();
 
		return self::$oInstance;
	}
 
	private function __construct()
	{
		$userData=httpContext::session()->getAttribute('user');
 
		if($userData{1})
		{
			$userData=unserialize($userData);
 
			$this->id=(int)$userData['id'];
			$this->lang=$userData['lang'];
		}
		else
		{
			$this->id=0;
			$this->lang=DEFAULT_LANG;
		}
	}
 
	public function isLoggedIn()
	{
		return ($this->id>0);
	}
 
	public function login($login,$pass)
	{
		$auth=authenticator::getInstance();
 
		$id=$auth->authenticate($login,$pass);
 
		if($id>0)
		{
			$this->id=$id;
			$this->lang=DEFAULT_LANG;
			return 1;
		}
		else
		{
			return 0;
		}
	}
 
	public function save()
	{
		httpContext::session()->setAttribute('user',serialize(array('id'=>$this->id,'lang'=>$this->lang)));
	}
 
	public function getLang()
	{
		return $this->lang;
	}
 
	public function logout()
	{
		$this->id=0;
	}
}
 
?>
[PHP] pobierz, plaintext 

I teraz w jaki sposob majac kontekst w kontrolerze obsluzysz taka klase jesli ona nie ma singletonu Bo wg mnie sztuka dla sztuki ( absurdem ) jest przekazywanie kotrolera z kontekstem do kazdej klasy

Ten post edytował NuLL 3.07.2006, 17:53:54