W naszej opowieści o wzorcu MVC pora zrobić krok dalej. Do eksperymentalnej implementacji Trinity dodaliśmy już całą procedurę rozruchową, moduły oraz hierarchiczne cegiełki pozwalające składać kontroler z mniejszych klocków. Mając już pewne rozeznanie, jak MVC działa i jakie możliwości, tudzież ograniczenia wprowadza w porównaniu z tym, co się implementuje we frameworkach, jesteśmy gotowi do rozważań na temat bardziej namacalny dla użytkownika końcowego, czyli nawigacji. Zastanowimy się, jak umieścić jej generowanie w strukturze wzorca oraz omówimy możliwe rozwiązania techniczne.

Przez ponad rok usługa Wave rozbudzała wyobraźnię programistów oraz użytkowników. Wiele osób, razem ze mną, dopatrywała się rewolucji w komunikacji internetowej. Mimo sporej ilości niedociągnięć, projekt dobrze rokował. Niestety na rokowaniach się skończyło. Wczoraj Google ogłosił zakończenie prac nad Google Wave.

Moje doświadczenia z “falą” były bardzo różne. Od zachwytu, po skrajną niechęć. Jednak cały czas gdzieś tam tliła się nadzieja, że Wave będzie przełomową technologią. Niestety problemy z wydajnością oraz złożoność usługi spowodowały, że niewiele osób zgłębiało tajniki tej technologii. Jak już opadł kurz i wszystkie “ochy” i “achy” przebrzmiały, zaczęto się zastanawiać, czy Wave ma rację bytu w naszym świecie. Czy jest biznesowo uzasadniony? Czy będzie w stanie usprawnić komunikację? Niestety nie będzie nam dane się przekonać, ponieważ do końca roku usługa najprawdopodobniej zniknie z Internetu.

Czy jest czego żałować? W sumie tak. Nie mogę się oprzeć wrażeniu, że Wave wyprzedzał swoją epokę i za kilka lat odżyje w innej postaci. Obecnie tylko garstka ludzi, była w stanie na tyle poznać Wave, że wiedzieli dokładnie gdzie i po co z niego korzystać. Zdecydowana większość użytkowników, po pierwszym zachwycie, nie wiedziała co z tym zrobić. Szkoda.

Piąta odsłona PHP dała programistom możliwość tworzenia przeciążonych właściwości oraz metod. Mimo iż funkcjonalność ta jest bardzo pomocna, to w przypadku naszpikowania klas metodami __set, __get, czy __call, tracimy możliwość szybkiego pisania kodu. Nasze IDE nie podpowie nam składni, ponieważ nie wie co ma podpowiedzieć. Czy przez wymienione wyżej metody skazani jesteśmy na nieustanne wertowanie dokumentacji? Nie. Dzięki PHPDoc mamy możliwość wskazania jakie właściwości i metody są przeciążane. Oto przykład:

/**
 * @property string $tekst
 * @property int $liczba
 * @property array $tablica
 * @method int someMethod()
 * @method string anotherMethod()
 */
class SomeClass
{
    protected $_data = array();
    
    public function __set($name, $value)
    {
        $this->_data[$name] = $value;
    }
    
    public function __get($name)
    {
        return $this->_data[$name];
    }
    
    public function __call($method, $args = array())
    {
        
    }
}

Podpowiadanie składni dla powyższej klasy będzie wyglądać nastęująco.

Rozwiązanie to ma jedną wadę. Nie jest podpowiadany typ właściwości oraz nie można określić jakie argumenty przyjmują przeciążane metody.

Bardzo mi odpowiada to regularne i częste wydawanie kolejnych wersji Zend Frameworka. Dzięki temu mamy potwierdzenie, że ZF się rozwija i społeczności zależy na poprawianiu jego funkcjonalności.

Co przynosi nam piątkowe wydanie ZF 1.10.7? Ponad 60 załatanych błędów. Ciekawsze poprawki tej wersji:

• Zend_Db_Adapter_Pdo_Pgsql (lastInsertId)
• Zend_Db_Table_Rowset_Abstract akceptował niepoprawne indeksy
• nieskończona pętla w StripTags
• Powiększenie funkcjonalności dla Google Apps -> Groups (Email Lists)
• Metoda removePrefixPath w Zend_Loader_PluginLoader.php usuwała ścieżkę z kluczem 0
• poprawki w Zend_Log::_constructFilterFromConfig()
• Popsuta implementacja S3_Stream
• problem z iconv_set_encoding() –> Zend_Service_Flickr
• Zend_Translate – poprawienie zarządzanie cachem

Download: Zend Framework 1.10.7

Zend Framework 1.11.0

A przed nami kolejna duża wersja ZF – 1.11. Powinna ukazać się pod koniec września 2010. Poza poprawieniem stabilności (wszelkie 1.10.X), kilka aktualizacji, normalizację tłumaczeń tekstów w walidatorach i kilka nowości.

Lada dzień zostanie wydany 1. milestone developerski ZF 2.0. Będzie już zmigrowany na przestrzenie nazw z PHP 5.3.

Dzisiaj prawdziwa gratka dla programistów PHP – PHP5. Zaawansowane programowanie. Nie owijając w bawełnę – książkę otrzyma osoba, która jako pierwsza poda datę, moich imienin. Powodzenia.

W jednym z niedawnych wpisów na internalsach, Felipe Pena przedstawił propozycję wprowadzenia typowania zwracanych zmiennych przez funkcje. Jest to funkcjonalność którą znamy z języków statycznie typowanych, gdzie każda funkcja musi mieć zdefiniowany typ zwracanej zmiennej. Propozycja opublikowana jako RFC zawiera patch, który każdy może przetestować u siebie, jeżeli wie jak kompilować php ze źródeł. Patch jest kompatybilny ze znajdującym się w trunku patchem dotyczącym typowania argumentów funkcji (dostępne są pseudotypy scalar i self bodajże).

Przykład (skopiowany z RFC):

function scalar abc($x = NULL) {
	return $x;
}
 
var_dump(abc(1));  // int(1)
var_dump(abc(1.)); // float(1)
var_dump(abc());
/*
PHP Catchable fatal error:  The returned value must be of the type scalar,
called in ... on line 9 and returning in ... on line 4
*/

Jak dla mnie sam feature może być, natomiast składnia nie do końca mi się podoba, wg mnie jest mało czytelna, wolałbym coś a’la ActionScript3:

function foo($arg):bar {
    return $arg+1;
}

A Wy co sądzicie o tym ficzerze ?

W poprzednim artykule z serii Domain Driven Design przedstawiłem pole zastosowań metodologii DDD, jej otoczkę w postaci zarządzania projektem oraz język domeny (DSL). W dzisiejszym wpisie chciałbym natomiast przedstawić metodologię DDD w sposób bliższy implementacji. Tak jak może już wspomniałem w poprzednim wpisie, metodologia DDD odnosi się do warstwy modelu w paradygmacie MVC. Natomiast wewnątrz tej warstwy modelu w MVC, DDD wprowadza rozdział na warstwę domenową (właściwy model) i warstwę infrastruktury. Dodatkowo istnieje kilka rodzajów obiektów, które mogą występować w obu warstwach:

• Encje (Entities)
• Wartości (Value Objects)
• Usługi (Services)

Czym jest warstwa domenowa ?

Warstwa domenowa odpowiada naszemu modelowanemu zagadnieniu a więc opierając się na poprzednim przykładzie hurtowni internetowej będą to obiekty takie jak Kontrahent, Przedstawiciel Handlowy, Faktura, Zamówienie, Oferta Handlowa etc.

Czym jest warstwa infrastruktury ?

Warstwa infrastruktury odpowiada za wszelkie „techniczne” działania jakie są potrzebne by warstwa domenowa mogła dobrze funkcjonować i współpracować z resztą aplikacji. A więc rzeczy typu utrwalanie (zapis do bazy), operacje na systemie plików, komunikacja z webservice’ami etc.

Typowym przedstawicielem warstwy infrastruktury są mappery relacyjno-obiektowe np. Doctrine. Jednak nie wszystkie z nich nadają się by być częścią warstwy infrastruktury, Doctrine w wersji 2 się nadaje, natomiast w wersji 1 nie. Dlaczego ? Metodologia DDD zakłada całkowity rozdział warstwy infrastruktury od warstwy domenowej, niestety chcąc utrwalać obiekty domenowe w Doctrine 1 musiały by dziedziczyć one z klasy Doctrine_Row co tworzy niepożądaną zależność. Dzięki temu, że warstwa domeny jest niezależna od warstwy infrastruktury możemy np. zmienić w którymś momencie ORM-a bez konieczności zmiany naszych klas w warstwie domeny.

Rodzaje obiektów

Wspomniałem wcześniej o kilku rodzajach obiektów, jak tworzyć więc klasy odpowiednich rodzajów ?

Klasy encji są to klasy które w konkretnym modelu domeny mają szczególne znaczenie, takie by stać się rozróżnialnymi (potocznie mówiąc mają własne ID). Klasy wartości natomiast różnią się od klas encji tym, że nie są rozróżnialne (potocznie mówiąc nie mają własnego ID, zawsze są przypisane do jakiejś encji). To czy dana klasa stanie się klasa encji czy wartości zależy od wielu czynników.

Załóżmy, że mamy aplikację do obsługi Urzędu Pocztowego, z modelowania wyszły nam dwie klasy Adres i Człowiek, w przypadku UP dla poczty najważniejszy jest adres i on też będzie encją, natomiast kto mieszka pod tym adresem jest w pewnym sensie sprawą drugorzędną (przynajmniej dla listów, które nie są polecone) będzie więc klasą wartości. Dla odmiany kiedy tworzymy aplikacje dla Hurtowni Internetowej to ważniejszy dla nas będzie Człowiek/Klient (on w końcu płaci za towar) i to on będzie encją, natomiast adres będzie wartością.

Trzecim rodzajem klas, które występują w DDD są klasy usług. Są to klasy, do których „wrzuca” się wszystkie metody, które nie pasują by je dołożyć do klas encji. Definicja ta niewiele mówi, nasuwa się więc pytanie – co powinno być w klasach encji ?

Metody w klasach encji powinny odpowiadać wszelkim (rzeczywistym) działaniom jakie wykonujemy na pojedynczym jej egzemplarzu. Przykładem niech będzie klasa Zamówienia z hurtowni internetowej. Będzie ona zawierać metody:

class Zamowienie {     
    public function dodajTowar($towar);
    public function usunTowar($towar);
    public function obliczCene();
    public function pobierzPodsumowanie();
    public function dodajOdbiorce($odbiorca);
    public function dodajRabat($rabat);
    public function wybierzSposobPlatnosci();
    public function wybierzSposobTransportu();
}

Co potrzebowalibyśmy jeszcze w kontekście zamówień ? Na pewno klient w swojej aplikacji chciałby mieć możliwość wyszukiwania Zamówień wg jakiś kryteriów, dotyczy to wszystkich zamówień, stworzymy więc klasę usługową, która będzie repozytorium zamówień. Jeżeli korzystamy z Doctrine’a 2, zostanie ona automatycznie wygenerowana przez ORM-a i będzie zawierała metody w rodzaju findBy(/*...*/), dzięki którym wyszukamy interesujące nas zamówienia. Repozytorium takie umożliwi również zapisywanie tych obiektów.

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Zwiń
Czytaj na blogu autora...