Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [Symfony][Symfony2][SF2] Jakie obiekty mają największy sens
Forum PHP.pl > Forum > PHP > Frameworki
Foxx
Załóżmy, że mamy następującą sytuację: użytkownik może podjąć się realizowania projektu, który składa się z wielu zadań.
Tworzę więc klasy: User, Project i Task. Podejmowanie projektu składa się z wykonywania kolejnych zadań i w każdym momencie musi być jasne które z zadań zostały już zrealizowane. Nie umiem się zdecydować co zrobić w momencie podejmowania zadania przez użytkownika.

Problemem dla mnie jest to, że chyba nie mogę po prostu utworzyć relacji między użytkownikiem, a projektem bo mimo, że miałbym wtedy wszystkie dane na temat zadań do wykonania to nie miałbym gdzie zapisać informacji na temat ich realizacji przez konkretnego użytkownika. Na przykład gdy użytkownik zakończy zadanie to muszę gdzieś zapisać datę tego zdarzenia.

Myślałem o stworzeniu kolejnych dwóch klas np. UserProject i UserTask, które reprezentowałyby podjęty projekt i jego zadania. W momencie podejmowania projektu z 10 zadaniami byłby dla danego użytkownika tworzony obiekt UserProject oraz 10 obiektów UserTask w realcji z UserProject. Mógłbym wtedy zapisać w tych nowych obiektach dowolne dane.

A może raczej powinienem tylko dodać projekt do myProjects obiektu użytkownik, a dopiero w trakcie realizowania kolejnych zadań tworzyć obiekty np. finishedTask? Ale gdzie mógłbym wtedy przechować informację o np. dacie podjęcia projektu?

A może jeszcze jakoś inaczej?
Ghost_78
Ja w takich sytuacjach lubie uzywac relacji n:m czyli tak jak napisales UserHasProject - to by byl dla mnie element laczacy.
pyro
A nie możesz po prostu stworzyć m:m między użytkownikiem a taskami? (m:m bo z tego co zrozumiałem jedno zadanie może być wykonane przez kilku userów)
Foxx
@Ghost_78: Istotne jest dla mnie przechowywanie kolejnych informacji w trakcie realizowania projektu, indywidualnych dla każdego z użytkowników. To o czym napisałeś to po prostu relacja między obiektami - to akurat nie byłoby problemem.

@Pyro: ale gdzie wtedy umieścić informację o dacie zakończenia zadania?
pyro
Niech no ja naszkicuję "profesjonalny" mockup, bo akurat mam chwilę...

// EDIT

Chciałem użyc Balsamiqa, ale nie mogłem się powstrzymać, żeby po latach uruchomić Painta do tego zadania, także sorry wink.gif

Foxx
Czyli, trzymając się kontekstu Symfony2, proponujesz stworzyć encję UserTask dla każdego z realizowanych zadań? Czyli to tak jakby ostatnia z moich propozycji, ta z finishedTask.

Mam co do tego rozwiązania wątpliwość z dwóch przyczyn: po pierwsze user podejmując projekt musi zrealizować (lub niezrealizować) wszystkie zadania z tego projektu. Nawet niezrealizowanie tego zadania będzie miało swoją reprezentację bo one będą do tego usera po kolei przychodzić. Po drugie podejmuje te zadania jedno po drugim w określonej kolejności. A więc nie ma tu zbyt dużo swobody, mogłem to opisać na samym początku. Twoje rozwiązanie pozwoliłoby realizować zadania w dowolnej kolejności i pomijać niektóre. Czy to nie zmienia sytuacji? Wiem, że nadal to może działać, ale czy teraz nadal to jest najlepsze wg Ciebie rozwiązanie? Bo widzę pewne problemy:

1. Użytkownik jest dwukrotnie powiązany z zadaniami - poprzez projekt oraz poprzez UserTask. Ale może to nie jest problem?

2. Przeprowadzanie niektórych istotnych operacji może być przykre, np: znajdź kolejne zadanie, które powinien teraz realizować user. Albo znajdź wszystkie zadania o danym statusie (status byłby w tabeli user_task) z wybranego projektu.

3. Bezpośrednie powiązanie usera z zadaniami - no sam nie wiem... jakoś czuję, że to mogłoby być bardziej eleganckie. User już jest powiązany z zadaniami poprzez projekt. Z drugiej strony moje propozycje na temat "klonowania" struktury projektu i jego zadań może są jeszcze mniej eleganckie...

A może to dobra propozycja i chodzi tylko o nomenklaturę bo staram się nie myśleć na razie o strukturze bazy tylko o obiektach. Gdyby Twoje user_tasks było klasą GrippedTask, która reprezentowałaby zadanie, które "przyszło" do usera i dyspozycją tych zadań zajmowałby się service ProjectManager to może byłoby odpowiednie?
pyro
Możesz w takim razie dokładniej opisać jak się odbywa przydzielanie tasków do użytkowników? W końcu kilka użytkowników może robić jeden task czy jak? Czy w ogóle cały project jest przypisany do jednego usera i tylko on może wykonać (w kolejności) wszystkie zadania z tego projektu?
Foxx
Już opisuję:

User decyduje się na wybrany projekt (jeden projekt naraz) spośród wielu projektów. Jeden user może zrealizować wiele projektów, jeden projekt może być realizowany przez wielu użytkowników.

Realizacja projektu polega na zrealizowaniu kolejno zadań, które są do niego przypisane. Jeden projekt może mieć wiele zadań, jedno zadanie należy tylko do jednego projektu. Kolejność przydzielania zadań jest zdeterminowana kolejnością, w której są one przypisane do projektu.

Zadania mają ustalone czasy trwania i po skończeniu się jednego zadania do użytkownika przychodzi kolejne. W trakcie realizowania zadania użytkownik może podjąć pewne akcje, które muszą być zapisane ponieważ mówią o sposobie realizacji zadania. Na przykład użytkownik może udzielić odpowiedzi w obrębie zadania, która musi zostać zapisana.
pyro
Ale task też może być realizowany przez kilku użytkowników?

Jeżeli tak to wystarczy do schematu wyżej po prostu dać pole `priority` dla `task`, które definiuje kolejność wykonywania tasków.
Foxx
Task może być realizowany przez kilku użytkowników. To jest tak, że mam projekt i jego składowe zadania. I teraz dowolny user, w dowolnej chwili może podjąć dowolny projekt i będzie realizował jego zadania. Ale nie będzie oczywiście operował na tych konkretnych zadaniach, które się składają na projekt tylko musi mieć jakieś własne ich instancje, w których zapiszą się różne informacje - to jest w sumie sedno mojego problemu. Gdyby użytkownicy mieli operować na tych konkretnych obiektach, które występują w jednej instancji i je modyfikowali, tak jak to jest np. z treścią artykułu na stronie internetowej gdy się go edytuje w CMSie to by nie było żadnego problemu.

Kolejność nie jest problemem. Zaznaczam tylko, że zależy ona od ułożenia zadań w projekcie po to, żeby przypomnieć że nie trzeba się tą kolejnością przychodzenia zajmować.
pyro
No to wygląda, że podane rozwiązanie jest tym czego potrzebujesz.

Cytat(Foxx @ 21.10.2013, 14:08:13 ) *
1. Użytkownik jest dwukrotnie powiązany z zadaniami - poprzez projekt oraz poprzez UserTask. Ale może to nie jest problem?


Raczej bym patrzył na to, że user jest powiązany z projektami oraz user jest powiązany z zadaniami. Samo przypisanie do projektu znaczy tylko tyle, że w nim uczestniczy i np. pojawi mu się na liście, ale niekoniecznie coś z nim jeszcze robił.

Cytat(Foxx @ 21.10.2013, 14:08:13 ) *
2. Przeprowadzanie niektórych istotnych operacji może być przykre, np: znajdź kolejne zadanie, które powinien teraz realizować user. Albo znajdź wszystkie zadania o danym statusie (status byłby w tabeli user_task) z wybranego projektu.


Gdzie tam, po prostu dobranie odpowiedniego zapytania.

Cytat(Foxx @ 21.10.2013, 14:08:13 ) *
3. Bezpośrednie powiązanie usera z zadaniami - no sam nie wiem... jakoś czuję, że to mogłoby być bardziej eleganckie. User już jest powiązany z zadaniami poprzez projekt. Z drugiej strony moje propozycje na temat "klonowania" struktury projektu i jego zadań może są jeszcze mniej eleganckie...


Napewno jest to lepsze rozwiązanie od klonowania struktury projektu (generalnie jest to antywzorzec). I tak jak wspomniałem - user będąc powiązany z projektami nie jest powiązany tak naprawdę z zadaniami.

// EDIT

Btw. sam temat z frameworkami i Sf2 ma związku tyle co nic. Raczej ORMy -> Doctrine
Foxx
Ok, dzięki. Przyjmę takie rozwiązanie, ale jeszcze pomyślę chwilę - napiszę gdybym to jeszcze zmodyfikował.

Dałem temat tutaj bo pomyślałem, że może kontekst SF2 może jakoś zmodyfikować/uprościć ten problem.
Ghost_78
W SF2 rozwiazywalem to w taki sposob ze robilem relacje n:m ale nie za pomoca ManyToMany ale tak jak pisal pyro - towrzylem sam tabele laczaca i w obu encjach robilem 1:n powiazanie z ta wlasnie tabela. Przy takim rozwiazaniu mozesz sobie dodac do tabeli laczacej co chcesz (tak jak rysowal pyro).

Jak dla mnie to jakos nie widze za bardzo sensu powiazywania usera z taskiem osobnymi relacjami. Jest on tak czy siak powiazany przez Projekt. Kwestia prezentacji zostaje po stronie skryptu wyswietlajacego.

Jezeli potrzebujesz jakis dodatkowych info do taska np. komenty albo inne bajery to po prostu dodaj kolejna tabele i w niej rob powiasanie user-task.
Foxx
Po namyśle wydaje mi się, że wiem jak to rozwiążę.
Przede wszystkim chciałem dodać informację, która chyba trochę umyka: Project i Task są tworzone w CMSie przez admina. Użytkownicy podejmują się realizacji projektów, ale nie modyfikują w żaden sposób obiektów Project i Task. Każdy użytkownik ma swoją indywidualną przygodę z projektem czyli z jego zadaniami.

W związku z tym potraktowanie Project i Task jako "matrycy" wydaje mi się uzasadnione. Moje obecne rozwiązanie polega na tym, że zmieniam nomenklaturę na Goal i Step - są to obiekty tworzone przez admina. User, który decyduje się realizować wybrany cel tworzy w tym momencie kolejny obiekt, który nazwę Project. Project będzie to Goal , który jest realizowany przez konkretnego użytkownika. Project będzie w relacji z Goal, ale nie będą to podobne obiekty - Project przechowuje informacje specyficzne dla danego użytkownika oraz informację o tym z jakiego Goal się wywodzi. Po stworzeniu Project od razu tworzę dla niego obiekty Task, które są odzwierciedleniem Step. Czyli Task analogicznie jest to Step, który będzie realizowany przez konkretnego użytkownika, w danym terminie i który przechowa też wynik.

Tworzę od razu wszystkie Tasks dla danego Projektu ponieważ i tak wszystkie muszą być stworzone. Tzn. w trakcie trwania projektu i tak każdy Task musi zostać przedstawiony userowi.

Efektem będzie relacja User - Project - Task. Project i Task będą w relacji ze swoimi "matrycami" - czy to jest akceptowalne rozwiązanie?

UPDATE:

Stworzę też klasę GoalServer, którą zarejestruję jako service i która będzie się zajmować tworzeniem projektów i zadań oraz generalnie zadaniami na tych obiektach, np. pobieraniem odpowiednich zestawów zadań, zadaniami na zadaniach uruchamianych z crona itp.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.