Kolejne dziś pytanie o architekturę SF2: gdzie jest odpowiednie miejsce na metody, które nie są bezpośrednio związane z encjami?
Na przykład metody obsługujące koszyk, który istnieje tylko w sesji.

możesz zrobić coś jak manager, który będzie serwisem.
np. BasketManager
tam robisz metody add, remove, pay...

@AxZx a dlaczego to ma się nazywać manager? Czy nie jest bardziej odpowiednią nazwą po prostu Basket.

Ciekawa lektura: http://stackoverflow.com/questions/1866794...whatevermanager

Gdzie jest? Hmmm... Jak dla mnie to zależnie od wielkości. Jeśli jest to całość pewna, to można by to jako bundle z własnymi kontrolerami i serwisami wypchnąć. Poza tym Koszyk sam w sobie, to już pewna funkcjonalność, która jest oparta nie tylko o jeden plik. To jest baza danych, aczkolwiek tylko pewne rzeczy z niej można pchnąć do zapisu prz użyciu silnika relacyjnego. No i kto powiedział, że skoro pracujemy z sesją, to nie ma encji czy ogólnie modelu danych?

Chyba duża część programistów o tym zapomina

Mały OT. Mnie o strukturze katalogów SF brakuje typowego katalogu app gdzie lądują pliki aplikacji, bo przecież nie wszystko da się upakować do bundla (niby masz AppBundle, ale jest to bundle nie używalny ponownie najczęściej, więc troszkę sensu nie ma). Ale chyba coś ma się zmienić w tej materii w 2.4.