Witam,
Ponieważ wcześniej pisałem tylko proste skrypciki, planuję pierwszą poważną aplikacje.
Znam MVC i frameworki PHP (CodeIgniter, CakePHP). Jednak mam kilka pytań do zawodowców.

1.Frontend i Backend
Jak je sensownie oddzielić? Mogę wszystkie akcje (czyli te zwykłe i dla admina) wrzucić do jednego kontrolera, ale trochę mi to nie pasuje.

2.Akcje dodawania i edycji rekordu
Są podobne, formularze prawie identyczne. Nie chciałbym powielać kodu. Jak realizujecie to u siebie - dwie osobne metody czy jedna z odpowiednia wartością, np edit = 0 / 1 ?

3.Cache
wiem, że po pewne dane nie ma sensu biegać do bazy, np ostatnie 10 artykułów/postów/komentarzy, itd - wystarczy sprawdzić czy są w cache, jeśli nie to wykonać zapytanie i wynik zapisać do pliku. Jeśli są to po prostu odczytać zawartość pliku. A co z pojedynczym rekordem i lista komentarzy pod spodem i liczba wszystkich np. newsów do paginacji - to tez zapisywać w cache? Zamiast czasu życia cache, myślę że lepsze będzie jego aktualizacja po wprowadzonych zmianach (dodaniu, aktualizacji czy usunięciu) - czyli tylko wtedy gdy zajdzie taka potrzeba. Czy jest to dobre podejście? Czy Backend aplikacji też cache`ujecie i używacie np. 2 różnych prefixów?

Dziękuję za ewentualną pomoc.

1. mówisz, że znasz MVC a zadajesz takie pytanie. Lepiej powtórz sobie zagadnienia
2. Edycja i dodawanie to dwie różne akcje. Więc nie. Możesz wydzielić metodę prywatną dla klasy zawierającą część wspólną obu metod.

1. Moduły Backend i Frontend - i najlepiej wspólne MODELE typu users, news itd.
2. Tworzysz 2 akcje np. addAction() i editAction($id). Do nich jeden formularz ale pobierający parametry z modelu np. users np:

addAction:

[PHP] pobierz, plaintext 
...
$form = UsersForm();
...
[PHP] pobierz, plaintext 

editAction($id)

[PHP] pobierz, plaintext 
$user = Users::findFirstById($id);
$form = new UsersForm($form,'edit');
[PHP] pobierz, plaintext 

3. Jeśli bawiłeś się w frameworki to pewnie dobrze wiesz, że są takie cuda jak partial itd.

Pozdro

nickyy dla mnie cashowanie ma sens tylko wtedy, gdy jakieś dane ładują się naprawdę długo, a aktualizacja danych nie jest zbyt częsta. Do cashowania najłatwiej jest wykorzystać funkcje buforowania: ob_start, ob_end_flush, ob_get_contents

@up a co ma buforowanie do cache?

Cashowanie daje ci trzymanie w pamięci, aby ponownie nie ładować danych - w tym przypadku by nie łączyć się ponownie z bazą danych. Zbuforowane dane zwraca funkcja ob_get_contents, co można wrzucić do pliku i ponownie odczytywać dane z pliku, a nie z bazy.

Co ty o tej gotówce w kółko?

Trzymanie w cache całej strony (wyciągniętej z bufora) to jest najgorszy pomysł jaki słyszałem. W cache trzyma się dane które są często odczytywane a się nie zmieniają np. 10 ost. art. na głównej czy dane o produkcie i jego powiązanych danych których wyjęcie jest kosztowne (to też nie do końca wszytko bo z tego mogą wyjść kwiatki), lub menu. Ale nie całe strony....

@Wazniak96: A co ma MVC do któregokolwiek z tych pytań?
@Pyton_000: Może chodzi o cache'owanie całych fragmentów HTML-a? Coś a'la ESI.

Właściwie to @aras785 wyczerpał temat:
- wspólna dla całej aplikacji warstwa logiki biznesowej oraz różne moduły/paczki/bundle/zwał-jak-zwał fragmenty aplikacji korzystające z niej,
- tworzenie i edycja obiektów, powinny być raczej realizowane przez osobne akcje, ale mogą one wykorzystywać wspólny kod, np. formularza,
- pamiętaj, że cache'ować powinno się raczej to co powoduje jakieś problemy z wydajnością czy stwarza wąskie gardła w systemie. Pobranie 10 ostatnich artykułów czy zliczenie ilości obiektów do paginacji nie będzie raczej czymś specjalnie kosztownym, ale to już zależy tylko i wyłącznie od Ciebie czy zdecydujesz się tam coś cache'ować i w jaki sposób będziesz to robić - ogólnie temat-rzeka.

EDIT:
@Pyton_000: Akurat cache całej strony czy gotowego fragmentu całej strony to bardzo dobre rozwiązanie bo pozwala na kompletne pominięcie procesu generowania strony - niestety często zwyczajnie w świecie nie da się z niego skorzystać.

Python_000, gdzie pisałem o ładowaniu całej strony ? Można tylko fragment - czyli treść pomiędzy ob_start, a ob_end_flush