Forum PHP.pl

DDD wykorzystuje się dla modelowania złożonych dziedzin. Jeżeli Twoja dziedzina składa się z produktu i komentarza i nie ma żadnych innych wymagań to nie jest to złożona dziedzina. Dla modelowania takiego przypadku służy właśnie CRUD. Jeżeli już koniecznie chcesz mieć DDD, to produkt i komentarz są encjami tego samego agregatu a produkt jest jego korzeniem. Skoro są w jednym agregacie to produkt zawiera komentarze, a nie referencje do nich. To jest wszystko co można zrobić dla tak zawężonego kontekstu.

Dlaczego chcesz unikać anemicznych encji w CRUDzie?

Możesz uznać wszystko za wszystko. Nie ma jednej precyzyjnie zdefiniowanej drogi i nie każdy program musi wyglądać tak samo. Jeśli już się uprzesz to encja jest jednym z bloków (wg DDD i building blocks), więc jest elementem dziedziny. Jeśli nie potrzebujesz id to je usuń a jeśli jest Ci potrzebne to zostaw, nie przyjdzie do Twojego domu inkwizycja sprawdzać czy encja ma "sztuczne" id czy nie.


Projekcje to raczej z event sourcingu, służą do przedstawienia stanu domeny i faktycznie użycie ich ma sens tylko w widoku. Przykładów w internecie jest wystarczająco.


Tego pomysłu chyba nie rozumiem, a w podanym przykładzie to już wszystko jest wymieszane ze wszystkim.

W jaki sposób ma załadować do formularza? Co rozumiesz przez ładowanie pliku do formularza?

Zajrzyj sobie do pliku config/routing_dev.yml i zobacz jakie jeszcze trasy powinieneś wykluczyć. Wybacz, ale mam jeszcze uwagę odnośnie metody onKernelRequest, ja nie lubię czytać takich długich warunków, zdecydowanie preferuję taki styl:

[PHP] pobierz, plaintext 
    public function onKernelRequest(GetResponseEvent $responseEvent)
    {
        $request = $responseEvent->getRequest();
        if (!$this->configurationManager->get('site_disabled')) {
            return;
        }
        if ($request->get('_route') === 'maintenance') {
            return;
        }
        if (strpos($request->get('_route'), 'admin_') !== false) {
            return;
        }
 
        $responseEvent->setResponse(new RedirectResponse($this->router->generate('maintenance')));
    }
[PHP] pobierz, plaintext 

Może jestem w błędzie i nie masz powtórzeń w kodzie, ale votery (zakładam, że mówimy o klasach a nie obiektach) dla każdej encji budzą takie podejrzenia. Ty widzisz swój kod i jak mówisz, że nie masz powtórzeń to spoko, mogę spać spokojniej.

Nie wiem jak wygląda Twój kod, ale jak to ma się do zasady DRY?

Mnie to nie irytuje, ten mechanizm jak dla mnie jest ok. Zastanów się czy nie możesz w takim wypadku stworzyć bardziej ogólnego votera.

Zawsze tak rozpatrujesz każdy element przykładu?


Tak, tylko bez tworzenia obiektu.

Proszę bardzo, Symfony Ci to umożliwia.

Strasznie mieszasz. W pierwszym Twoim przykładzie oryginalną usługą jest 'old' i dekorujesz ją usługą 'dekorator'. Sprawdzanie co ma 'dekorator' nie ma żadnego sensu bo to jest oczywiste. Sprawdź co po takim dekorowaniu zawiera usługa 'old'.

Znasz w ogóle wzorzec dekoratora?

Wiesz o tym, że nadpisywanie to co innego niż dekorowanie? Przecież dekorator potrzebuje starej usługi, jeżeli chcesz tylko nadpisać i zapomnieć o starej usłudze to nie potrzebujesz dekoratora. Ale to wszystko masz przecież opisane w dokumentacji, w pierwszych zdaniach spod załączonego przez Ciebie adresu.

Po to możesz skorzystać z factory, żeby wykorzystać fabrykę Twoich obiektów. Extension (moim zdaniem) ma całkiem inne zadanie od fabryki, służu raczej do ułatwienia konfiguracji DiC a nie do tworzenia obiektów.

http://symfony.com/blog/new-in-symfony-2-6...nt-improvements

factory i calls to są dwie różne rzeczy. Factory tworzy Twój obiekt, a calls wywołuje funkcje na tym utworzonym obiekcie. Możesz fabryką utworzyć obiekt a potem wywołać na nim metodę.

Jeszcze prościej będzie zrobić to w kontrolerze.

To jest dopiero pomysł, żeby w repozytorium sprawdzać uprawnienia.

Tylko, że każdy na tym serwerze może mieć postawioną swoją wirtualną maszynę, lub pracować w katalogach użytkownika i pewnie jeszcze kilka innych rozwiązań.

Dlaczego?

Napisałeś, że chodzi o php i twig. Masz podane rozwiązanie w twigu i częściowo w php, jak połączysz informacje to będziesz wiedział.

Po za tym nie wiem jak mam rozumieć "globalnie w php".

To nie mam pojęcia gdzie tego szukałeś, skoro nawet na stronie do której podałeś adres podane jest rozwiązanie Twojego problemu.

Tak jak w dokumentacji.

To zawsze nie jest prosta sprawa żeby znaleźć poprzez takie doradzanie i szczątkowe informacje co jest przyczyną. Obstawiam, że masz źle skonfigurowany opcache i nie zachowuje on komentarzy w których trzymasz routing.

Musisz zainstalować serwer smtp i imap.

Dziękuję, starałem się.

Nie wiem czy jest Ci potrzebny REST więc nie wiem czy musisz się go uczyć. Podstawowym założeniem Symfony jest aby nie robić nic w tle. Na pewno rozumiesz czym jest REST?

Dla tych co potrzebują REST i ta paczka spełnia ich oczekiwania.