Symfony organizacja bundli

Witam, zastanawiam się nad najlepszą organizacją bundli w projekcie wykorzystując FW Symfony (3.x).

Podchodząc do bundli, traktuje je jak pakiet, który dostarcza pewną funkcjonalność dla aplikacji.

Teraz zakładając, że moją aplikacją będzie sklep internetowy zbieram myśli nad tym jaką funkcjonalność będzie miała aplikacja i tu mogę powoli przystępować do tworzenia bundli więc tak:

• Potrzebuje kategorie, subkategorie więc szybko przychodzi na myśl:
  Stwórz CategoryBundle - pakiet będzie odpowiadał za - dodawanie kategorii, usuwanie kategorii, wyszukiwanie danej kategorii, szukanie rodzica dla kategorii dziecko (w końcu w sklepie mogę sprzedawać Produkty RTV, ale również Odzież dla dorosłych)

• Potrzebuje systemu płatności więc:
  Stwórz PaymentBundle - pakiet odpowiada za przyjmowanie / weryfikowanie płatności

• Potrzebuje koszyka więc:
  Stwórz BasketBundle - przechowuj produkty, itd, itd

• Potrzebuje produktów więc:
  Stwórz ProductBundle - dodawanie produktu, usuwanie produktu, sprawdzanie ilości produktów na stanie itd.

I jakiś zarys bundli mam w głowie, ale brnąc dalej w pakiecie ,,ProductBundle" dodając produkt trzeba przypisać go do kategorii, a same kategorie znajdują się w pakiecie CategoryBundle i teraz robi się zależność ,,Jeżeli pakiet ProductBundle nie dostanie ID kategorii z CategoryBundle pakiet nie będzie działać".

Czy powyższa organizacja bundli jest prawidłowa ? Czy faktycznie tworząc jeden pakiet powinien on być niezależny od drugiego ?

Z drugiej strony można by przygotować pakiet, który nazywa się ProductBundle, a w nim przygotować całą architekturę wraz z kategoriami (ale wtedy to będzie pakiet odpowiadający za tworzenie kategorii, dodawanie produktów)

Które podejście jest prawidłowe i jak Wy rozwiązujecie problemy tego typu ?

Zależności między pakietami, modułami czy bundlami nie unikniesz - choć powinieneś próbować je minimalizować (low coupling & high cohesion).

Twoje myślenie jest dobre - po przykład rzuć okiem na kod Syliusa :-)

Sylius fajny przykład i autorem Polak, ogólnie po projekcie widać, że jest ładnie zorganizowany, ale trzeba przyznać, że to organizacja pod typowo duży sklep wątpię, że któreś z mniejszych sklepów są aż tak zorganizowane.

Jednakże jak ktoś będzie kiedyś miał przemyślenia odnośnie bundli w projekcie to faktycznie dobry przykład.

Sprzedaż czegokolwiek przez swoją platformę / oprogramowanie, narzuca samo z siebie wiele rzeczy, wynika to wprost z przepisów.

Dodatkowo w mojej ocenie rynek wymusza automatyzację / dobre oprogramowanie już przy skali sprzedaży większej niż około 30 paczek dziennie, bo im więcej zatrudnisz osób do ręcznej obsługi zamówień tym mniej konkurencyjny jesteś.

Rynek już zaczyna się konsolidować, i z małych sklepów pozostaną tylko nisze.

Dlatego radzę Ci przygotować się na większą ilość elementów systemu niż przedstawiłeś. Skoro tych elementów będzie więcej, i będą coraz bardziej między sobą powiązane, to sięzastanów nad zrobieniem jednego dużego bundla sklepu. Inaczej będziesz miał sklep złożony z kilkudziesięciu różnych bundles, które teoretycznie powinny działać samodzielnie standalone (bo taki jest sens ich robienia), a praktycznie to wymagałoby ogromnej ilości pracy (w porównaniu z jednym bundlem), której pewnie i tak nie wykonasz.

Przykładowo sklep którym ja się zajmuje, ma około 140 relacji SQL i NoSQL, oraz kilka tysięcy klas PHP, i jest to sklep mały/średni.

Skoro tych elementów będzie więcej, i będą coraz bardziej między sobą powiązane, to sięzastanów nad zrobieniem jednego dużego bundla sklepu. Inaczej będziesz miał sklep złożony z kilkudziesięciu różnych bundles

Skoro tych elementów będzie więcej tzn, że w jednym bundlu będę miał pięknie scrollowana liste plików z kontrolerami etc w ogóle mi się to nie widzi ;-D.

Przykładowo sklep którym ja się zajmuje, ma około 140 relacji SQL i NoSQL, oraz kilka tysięcy klas PHP, i jest to sklep mały/średni.

Jeżeli masz bundle'a od kategorii to według mnie ten bundle powinien ,,sprężać" zależności innych pomysłów.
Bynajmniej ja to tak widze, że jest tabela:

• Kategoria
• Cechy dla kategorii
• Wartości cech dla kategorii

I między tabelami odbywają się jakieś relacje dla mnie to nadal jest jeden bundle (CategoryBundle), a spakowanie tego w jeden bundle (AppBundle) i dopakowanie teraz produktów do tego samego pakietu znacznie utrudni przejrzystość i rozbudowe/modyfikację.

Rynek już zaczyna się konsolidować, i z małych sklepów pozostaną tylko nisze.

Ahhh jak ja bym chciał zobaczyć te czasy kiedy małe sklepiki upadają, a typowy student-janusz nie tworzy softu z kosmosu dla janusza-biznesu, dla którego jakość kodu się nie liczy tylko czas realizacji oraz wynagrodzenie ;-x

cóż, moje doświadczenia są zupełnie odwrotne i to właśnie te projekty pisane na odpieprz przepalają więcej pieniędzy, ponieważ nagle zmiana w module do komunikacji z Allegro powoduje wywalenie się integracji z Magento

albo sama aplikacja jest tak oprogramowana, że dalsze ładowanie w nią kosztów nie ma sensu.

Bundle = teoretycznie całkowicie niezależny kod, który może być przenoszony między aplikacjami.

Jeżeli stworzysz bundle dla kategorii, to aby to był prawdziwy bundle, to powinno się go bez żadnych problemów przenosić pomiędzy innymi aplikacjami, nie ważne czy to seriws randkowy czy sklep.

To oznacza dodatkowy narzut pracy, i teraz zastanów się czy na pewno tego potrzebujesz, czy te dodatkowe godziny pracy (i tym samym koszt) są niezbędne, są opłacalne.

Natomiast jeżeli tego nie zrobisz, to nie będzie taki do końca prawdziwy bundle, będzie to taka wydzielona logicznie część aplikacji, ale nie prawdziwy przenośny plugin - i pewnie o to Ci chodzi(?).

Tak w ogóle, w najnowszej wersji Symfony od Bundli się odchodzi:

https://symfony.com/doc/current/bundles.html

Bundle = teoretycznie całkowicie niezależny kod, który może być przenoszony między aplikacjami.
Jeżeli stworzysz bundle dla kategorii, to aby to był prawdziwy bundle, to powinno się go bez żadnych problemów przenosić pomiędzy innymi aplikacjami, nie ważne czy to seriws randkowy czy sklep.

Załóżmy, że tak jest, ale w praktyce nie wychodzi chyba zbyt wiele ,,bundli" tego typu

To oznacza dodatkowy narzut pracy, i teraz zastanów się czy na pewno tego potrzebujesz, czy te dodatkowe godziny pracy (i tym samym koszt) są niezbędne, są opłacalne.

Właśnie tworzenie bundla, który nie będzie zależny od innego bundla nie do końca jest metodą, którą chce obrać bardziej mam w planach pogrupować projekt w stylu:
CategoryBundle -> odpowiada za kategorie etc
ProductBundle -> odpowiada za produkty, ale ich kategorie są czerpane od bundla Category

Nie opłaca mi się uciekać od takiego rozwiązania czasowo, a wydaje mi się, że tak jest najbardziej ,,czytelnie" gdyby w razie potrzeby trzeba było wrócić coś dodać czy modyfikować.

Natomiast jeżeli tego nie zrobisz, to nie będzie taki do końca prawdziwy bundle, będzie to taka wydzielona logicznie część aplikacji, ale nie prawdziwy przenośny plugin - i pewnie o to Ci chodzi(?).

Post zakładałem z myślą bardziej ,,jak dobrze zorganizować bundle by łatwo wrócić do kodu gdy zajdzie taka potrzeba".

Nie wiem jak do Ciebie, ale do mnie struktura taka jak:

src

• AppBundle
  -- Controller
  --- CategoryController
  --- ProductController
  --- ShopController
  --- 50xController
  -- Entity
  --- Product
  --- 50xEntity

W ogóle nie przemawia ;-S.

Tak w ogóle, w najnowszej wersji Symfony od Bundli się odchodzi:

O tym nie czytałem, ale to dlatego, że myślałem bardziej o wersji 3.4 ze względu na ,,lts".

Do mnie ogólnie Symfony "nie przemawia", dlatego wtedy kiedy mogę wybrać, to wolę pracować z Phalconem, gdzie zrobiłem sobie swoją organizację katalogów.

Zrobiłem to w ten sposób, że są generalnie trzy podstawowe katalogi: public, nopub (niepubliczny), oraz class - na klasy.

I teraz każdy większy element to osobny katalog.

Na przykładzie kategorii, które byłyby w namespace /myshop/category byłoby:

• public/myshop/category - pliki gif, js etc dla kategorii

• nopub/myshop/category - głównie pliki szablonów, i inne pliki które nie powinny być dostępne z zew.

• class/myshop/category/CategoryEntity.php - klasa encji dla kategorii, i inne klasy związane z kategorią: kontrolery, etc.

Odkryłem, że taki system gdzie katalogi odpowiadają namespace nie tylko w katalogu klas, bardzo ładnie się sprawdza.

Czyli nie masz jakiegoś dedykowanego katalogu na kontrolery czu modele, wszystko opiera się modularnie o namespaces komponentów. Dla mnie bomba, a nie to co proponuje Symfony, i wiele innych FW narzucających/proponujących dużo różnych katalogów. W mojej strukturze są tylko trzy katalogi, a reszta to namespaces.

Czasami mam wrażenie, że koncepcje struktur każdy obiera sobie według swoich ,,upodobań".
Nawet przeglądając projekty w Symfony ludzie nie trzymają się wytycznych zalecanych i każdy ,,pisze sobie".

Może i ja niepotrzebnie szukam sztuki na siłę i po prostu powinienem zrobić to swoją koncepcją, która będzie dla mnie najbardziej przejrzysta.