| Autor | Zpráva | ||
|---|---|---|---|
| Jirin Profil |
Chci dělat systém, který bude mít na sobě nezávislé moduly. A chtěl bych nasadit Dcotrine. Nicméně jde udělat nezávisle entity?
Uvedu příklad mějme články a komentáře.Chtěl bych mít samostatně nezávislou entitu Article a nezávislou entitu Comment. Protože zkrátka někdy můžu chtít člányk s komentáři jindy bez, případně komentáře použít jinde. No a když budu chtí články s komentáři tak samozřejmě tam budu mít v entitě vazbu komentář-článek, ale někdy zase ne. Jak tohle řešíte a je ot ešitelné vůbec? Vím, že existuje v Doctrine ResolveTargetEntityListener. Nicméně tne to podle mě neřeší ten řeší to, že bude Entita záviset na jiné s určitým interface, nicméně neřeší to nijak, že někdy tam bude a někdy bude nulová nebo ano? |
||
| Majkl578 Profil |
#2 · Zasláno: 15. 4. 2013, 15:18:26
V dokumentaci je přesně na toto téma pěkný článek, ten jsi četl?
|
||
| Jirin Profil |
#3 · Zasláno: 15. 4. 2013, 16:00:04
Ano četl, však ho v posledním odstavci zmiňuji. Nicméně pochopil jsem to tak, že tam ta vazba je vždy a nejde, že by byla ta vazba null. Nebo jsem to špatně pochopil?
|
||
| Majkl578 Profil |
#4 · Zasláno: 15. 4. 2013, 19:25:42
Vazby jsou v Doctrine nulové defaultně, pokud není uvedeno jinak (tj. např.
@ORM\JoinColumn(nullable=false)).
„zkrátka někdy můžu chtít člányk s komentáři jindy bez“ Tohle je ale jiný problém, související se samotným návrhem, ne s nezávislostí modulů. Buď může mít každý článek vazbu na komentáře a aplikační logika by pak očetřovala samotnou možnost existence komentářů, nebo lze mít např CommentableArticle s vazbou na komentáře dědící od Article bez komentářů. „případně komentáře použít jinde“ Z pohledu vazby tohle nedává smysl. Pokud chceš komentář používat na různých místech (tj. i jinde než u článků apod.), neměla by vazba vést obousměrně, ale jednosměrně (1:N) s join tabulkou (viz One-To-Many, Unidirectional with Join Table). Jinak bys u komentáře musel mít vazbu na každý typ, který je komentovatelný, což zřejmě nebude správně. |
||
| Jirin Profil |
#5 · Zasláno: 18. 4. 2013, 00:15:59
Díky za odpověď, ano tím potomkem CommentableArticle apod to mohu řešit, jenže je tam problém, že těch "specifických věcí mohu mít více. Napadá mě třeba budu chtít přidat autora k článku, případně kategorie a to by pak bylo xxx potomků. Zkrátka bych chtěl ideálně něco na způsob mám základní třídu article, a jak ji zavedu mohu si dodat další atributy.
S moduly to má hodně společného. Chci například modul obsluhující ryze jen článek, potom modul obsluhující jen komentáře. No a pak ten komentářový modul budu chtít použít třeba pod produkty v eshopu, nebo potom jako komentáře k anketě. Zkrátka bych potřeboval nějakou základní entitu a tu pak při nasazení rozšířit o to, na co ji budu konkrétně potřebovat, ale tak abych do té původní entity nesahal. Např. bych měl další modul který by tu entity "překryl" nebo tak. Je to v doctrine řešitelné? S tou jednosměrnou vazbou jinak máš pravdu, tak by to šlo řešit, sice tam přidju o tu snadnou možnost, že mi entita Article vrátí list komentářů, ale s tím se moc nedá dělat, tak to mi bude vracet verstva výše:) |
||
| aDAm Profil |
#6 · Zasláno: 18. 4. 2013, 14:21:12
Nevím zda tě chápu přesně, ale udělej s globální entitu "Komentář" co bude mít prvky pro všechny společné a nad ní postav jednotlivé entity pro komentáře článku, ankety, produktu atd a tyto entity budou tu hlavní dědit.
|
||
| Jirin Profil |
#7 · Zasláno: 18. 4. 2013, 19:13:20
Ano, tak to je řešitelné celkem, ale obává mse výkonosti. Protože když takhle udělám článek třeba, tak tam bych chtěl mít volitelné například, kategorie, autor, tagy atd atd. No a to uz bych těch překrývajících zděděných tříd dělal asi moc..
Ono jde na to taky přistoupit i obráceně, udělat naopak entitu s co nejvíce atributy a pak by se ty atributy co nechtěli "vyškrtli", ale to taky nijak asi nejde, abych řekl, tohle nepoužívej. A tak by ta databáze podle toho byla stejně vygenerovaná. |
||
|
Časová prodleva: 12 let
|
|||
0