Encje doktrynalne i logika biznesowa w aplikacji Symfony

Zobacz tutaj: Sf2: korzystanie z usługi wewnątrz podmiotu

W twoim konkretnym pytaniu, powiedziałbym, że jest tu "sztuczka"... co to jest "grupa"? "Sam"? czy to, gdy odnosi się do kogoś?

Początkowo Twoje klasy modelowe prawdopodobnie wyglądałyby tak:

UserManager (service, entry point for all others)

Users
User
Groups
Group
Roles
Role

UserManager miałby metody pobierania obiektów modelu (jak powiedziano w tej odpowiedzi, nigdy nie powinieneś robić new). W kontrolerze można to zrobić:

$userManager = $this->get( 'myproject.user.manager' );
$user = $userManager->getUserById( 33 );
$user->whatever();

Wtedy... User, jak mówisz, może mieć role, które mogą być przypisane lub nie.

// Using metalanguage similar to C++ to show return datatypes.
User
{
    // Role managing
    Roles getAllRolesTheUserHasInAnyGroup();
    void  addRoleById( Id $roleId, Id $groupId );
    void  removeRoleById( Id $roleId );

    // Group managing
    Groups getGroups();
    void   addGroupById( Id $groupId );
    void   removeGroupById( Id $groupId );
}

Uprościłem, oczywiście można dodać po Id, dodać po obiekcie itp.

Ale kiedy myślisz o tym w "języku naturalnym"... zobaczmy...

Wiem, że Alice należy do fotografów.
1. dostaję obiekt Alice.
Zapytuję Alice o grupy. I get the grupowych fotografów.
2. pytam fotografów o role.

Zobacz więcej szczegółów:

1. wiem, że Alice jest użytkownikiem id = 33 i jest w grupie fotografa.
2. proszę Alice do Usermanagera przez $user = $manager->getUserById( 33 );
Nie jest to jednak możliwe, ponieważ nie jest to możliwe, ponieważ nie jest to możliwe.]}
3. chciałbym zobaczyć role grupy... Co mam zrobić?
   • Opcja 1: $group- > getRoles ();
   • Opcja 2: $ group- > getRolesForUser ($userId);

Drugi jest jakby zbędny, ponieważ dostałem grupę przez Alice. Możesz utworzyć nową klasę GroupSpecificToUser, która dziedziczy z Group.

Podobne do gry... co to jest gra? "Gra" jako "szachy" w ogóle? Czy ta konkretna " gra " w "szachy", którą zaczęliśmy wczoraj?

W tym przypadku $user->getGroups() zwróci zbiór grup obiektów.

GroupSpecificToUser extends Group
{
    User getPointOfViewUser()
    Roles getRoles()
}

To drugie podejście pozwoli Ci zamknąć tam wiele innych rzeczy, które wcześniej czy później się pojawią: czy ten użytkownik może coś tutaj zrobić? możesz po prostu odpytywać podklasę grupy: $group->allowedToPost();, $group->allowedToChangeName();, $group->allowedToUploadImage();, itd.

W każdym razie, można uniknąć tworzenia taht weird class i po prostu zapytać użytkownika o te informacje, jak podejście $user->getRolesForGroup( $groupId );.

Model nie jest warstwą persistance

Lubię "zapomnieć" o perystancji, gdy projektowanie. Zazwyczaj siedzę z moim zespołem (lub ze sobą, dla projektów osobistych) i spędzam 4 lub 6 godzin na rozmyślaniu przed napisaniem dowolnej linii kodu. Piszemy API w dokumencie txt. Następnie iterować na nim dodawanie, usuwanie metod, itp.

User
    getId()
    getName()
    getAllGroups()                     // Returns all the groups to which the user belongs.
    getAllRoles()                      // Returns the list of roles the user has in any possible group.
    getRolesOfACertainGroup( $group )  // Returns the list of groups for which the user has that specific role.
    getGroupsOfRole( $role )           // Returns all the roles the user has in a specific group.
    addRoleToGroup( $group, $role )
    removeRoleFromGroup( $group, $role )
    removeFromGroup()                  // Probably you want to remove the user from a group without having to loop over all the roles.
    // removeRole() ??                 // Maybe you want (or not) remove all admin privileges to this user, no care of what groups.

Group
    getId()
    getName()
    getAllUsers()
    getAllRoles()
    getAllUsersWithRole( $role )
    getAllRolesOfUser( $user )
    addUserWithRole( $user, $role )
    removeUserWithRole( $user, $role )
    removeUser( $user )                 // Probably you want to be able to remove a user completely instead of doing it role by role.
    // removeRole( $role ) ??           // Probably you don't want to be able to remove all the roles at a time (say, remove all admins, and leave the group without any admin)

Roles
    getId()
    getName()
    getAllUsers()                  // All users that have this role in one or another group.
    getAllGroups()                 // All groups for which any user has this role.
    getAllUsersForGroup( $group )  // All users that have this role in the given group.
    getAllGroupsForUser( $user )   // All groups for which the given user is granted that role
    // Querying redundantly is natural, but maybe "adding this user to this group"
    // from the role object is a bit weird, and we already have the add group
    // to the user and its redundant add user to group.
    // Adding it to here maybe is too much.

Wydarzenia

Jak wspomniano w wskazanym artykule, rzuciłbym również zdarzenia w modelu,

Na przykład, gdy usuwając rolę od użytkownika w grupie, mogłem wykryć w "słuchaczu", że jeśli był to ostatni administrator, mogę a) anulować usunięcie roli, b) zezwolić na to i opuścić grupę bez administratora, c) zezwolić na to, ale wybrać nowego administratora z użytkowników w grupie, itp lub jakąkolwiek politykę jest odpowiednia dla Ciebie.

W ten sam sposób, być może użytkownik może należeć tylko do 50 grup (jak w LinkedIn). Możesz wtedy po prostu rzucić Zdarzenie preAddUserToGroup i każdy łapacz może zawierać Regulamin zabraniający tego, gdy użytkownik chce dołączyć do grupy 51.

Ta "reguła" może wyraźnie opuścić klasę User, Group i Role i opuścić klasę wyższego poziomu, która zawiera "reguły", według których użytkownicy mogą dołączać lub opuszczać grupy.

Zdecydowanie sugeruję, aby zobaczyć drugą odpowiedź.

Mam nadzieję pomóc!

Xavi.

Jako osobiste preferencje Lubię zaczynać prosto i rozwijać się, gdy stosuje się więcej reguł biznesowych. Jako taki mam tendencję do faworyzowania słuchacze podchodzą lepiej .

You just

• dodaj więcej słuchaczy w miarę rozwoju reguł biznesowych ,
• każdy ma jedną odpowiedzialność ,
• i możeszprzetestować tych słuchaczy niezależnie łatwiej.

Coś, co wymagałoby wielu kpin / stubów, jeśli masz jedną usługę klasa:

class SomeService 
{
    function someMethod($argA, $argB)
    {
        // some logic A.
        ... 
        // some logic B.
        ...

        // feature you want to test.
        ...

        // some logic C.
        ...
    }
}

Jestem zabiznesowymi podmiotami. Doctrine idzie długą drogę, aby nie zanieczyszczać Twojego modelu problemami z infrastrukturą ; używa refleksji, więc możesz dowolnie modyfikować Accesory, jak chcesz. 2" doktrynalne " rzeczy, które mogą pozostać w klasach encji, to adnotacje (których można uniknąć dzięki mapowaniu YML)oraz ArrayCollection. Jest to biblioteka poza doktryną ORM (Doctrine/Common), więc nie ma tam żadnych problemów.

Więc, trzymając się podstaw DDD, byty są naprawdę miejscem, w którym można umieścić twoja logika domeny. Oczywiście czasami to nie wystarczy, wtedy możesz dodać domain services , usługi bez obaw o infrastrukturę.

Doctrine repozytoria są bardziej pośrednie: wolę je zachować jako jedyny sposób na zapytanie o encje, event, jeśli nie trzymają się pierwotnego wzorca repozytorium i wolałbym usunąć wygenerowane metody. Dodanie usługi manager do enkapsulacji wszystkich operacji fetch/save danej klasy było powszechna praktyka Symfonii kilka lat temu, nie bardzo mi się to podoba.

Z mojego doświadczenia wynika, że możesz mieć znacznie więcej problemów z komponentem Symfony form, Nie wiem czy go używasz. Będą one serisouly ograniczyć możliwość dostosowania konstruktora, wtedy można raczej używać nazwanych konstruktorów. Dodanie znacznika PhpDoc @deprecated̀ spowoduje, że Twoje pary otrzymają wizualną informację zwrotną, której nie powinny pozwać oryginalnego konstruktora.

Wreszcie, ale nie mniej ważne, poleganie zbytnio na wydarzeniach doktrynalnych w końcu ugryzie ty. Są tam zbyt wiele ograniczeń technicznych, Plus uważam, że trudno je śledzić. W razie potrzeby dodaję zdarzenia domeny wysłane z kontrolera/polecenia do dyspozytora zdarzeń Symfony.

Rozważyłbym użycie warstwy usługowej oprócz samych Bytów. Klasy encji powinny opisywać struktury danych i ewentualnie inne proste obliczenia. Złożone zasady idą do usług.

Dopóki korzystasz z usług, możesz tworzyć więcej systemów, usług itd. Możesz skorzystać z dependency injection i wykorzystać zdarzenia (dyspozytorów i słuchaczy) do komunikacji między usługami, utrzymując je słabo połączone.

I say that na podstawie własnego doświadczenia. Na początku umieszczałem całą logikę wewnątrz klas encji (szczególnie gdy tworzyłem symfony 1.x / Doktryna 1.x aplikacji). Tak długo, jak aplikacje rosły, stały się naprawdę trudne do utrzymania.