To naprawdę zależy od definicji "duży". Czy odnosisz się do dużych zestawów danych? Bardzo skomplikowany model domeny?Lub po prostu wiele różnych kontrolerów/działań?
Zapisywanie/odczytywanie danych.
Wszystko, co można zrobić za pomocą zwykłego kodu SQL, który można wykonać w CakePHP. Nie zawsze jest to przyjemne, ale w najgorszym przypadku nie jest gorsze od prostego kodu SQL.
Ale naprawdę nie powinieneś myśleć o zapytaniach. Powinieneś pomyśleć o swoim modelu domeny. CakePHP implementuje aktywny wzór rekordu. Działa to bardzo dobrze, jeśli twój model domeny ładnie ładnie odwzorowuje aktywny wzór rekordu. Ale jeśli nie, to nie polecam CakePHP. Jeśli twój model domeny nie jest mapowany do Aktywnego Rekordu, spędzasz dużo czasu walcząc z metodą Cake. I to nie jest zabawa. Byłoby znacznie lepiej z ramy, które implementuje wzorzec mapowania danych (np. Zend).
Rusztowania
Rusztowanie jest tymczasowy. Obsługuje klucze obce (jeśli je zdefiniujesz w modelu, jak również w bazie danych), ale to wszystko. Nie można modyfikować rusztowania. Ale możesz je upiec!
Po upieczeniu kontrolera lub widoku zasadniczo zapisujesz rusztowanie do pliku jako punkt wyjścia dla własnej implementacji. Po upieczeniu możesz zrobić wszystko, co chcesz. Minusem wypieku jest to, że nie aktualizuje się, gdy modele lub baza danych się zmienia. Jeśli więc wypiekasz kontroler i widoki i dodasz pola do swojego modelu, musisz ręcznie dodać te pola do kontrolera i wyświetlić kod.
szybkość rozwoju
w moim przypadku, jestem dużo szybszy rozwój strony internetowej w CakePHP następnie w zwykłym kodzie. Ale tylko jeśli Active Record pasuje do aplikacji! Zobacz mój pierwszy punkt. Nawet wtedy Cake jest prawdopodobnie jeszcze szybszy, ale byłbym jeszcze szybszy dzięki lepszej strukturze kostiumów.
Niektóre inne myśli
dużych zbiorów danych
jeśli masz bardzo dużych zbiorów danych i duże wyniki kwerendy następnie ciasto może być problem. Operacja find() chce zwrócić tablicę asocjacyjną, aby wszystkie wiersze były odczytywane, analizowane i konwertowane na tablice. Jeśli twój zestaw wyników jest zbyt duży, zabraknie Ci pamięci. CakePHP nie implementuje obiektów ResultSet, jak wiele innych implementacji Active Record i jest to zdecydowanym minusem. Kończysz ręczne stronicowanie przez własne dane z podzapytaniami. Fuj. Wich prowadzi mnie do następnego punktu:
tablice
Naucz się kochać je, ponieważ CakePHP robi. Wszystko jest uporządkowane i często są duże, złożone i głębokie. Po pewnym czasie robi się naprawdę denerwująco. Nie możesz dodawać funkcji do tablic, więc twój kod jest bardziej brudny niż gdyby CakePHP użył instancji zagnieżdżonych obiektów. Funkcje, które można dodać do tych obiektów, mogą pomóc w utrzymaniu kodu w czystości.
dziwactwa i niespójności
CakePHP ma prawdziwych nieprzyjemnych stinkers ukryte głęboko wewnątrz.Jeśli Active Record pasuje do twojej aplikacji, prawdopodobnie nigdy nie natkniesz się na nie, ale jeśli spróbujesz przekształcić CakePHP w coś bardziej złożonego, będziesz musiał z nimi walczyć. Kilka przykładów:
- HABTM w niestandardowym modelu używa definicji z drugiej strony relacji, nad którą pracujesz.
- Kilka naprawdę dziwnych miejsc, w których twoje wyzwalacze przed/po nie są wywoływane (na przykład nie od aktualizacji)
- nieparzyste zachowanie Model-> field(). Zawsze wysyła zapytania z bazy danych. Uważaj więc na aktualizowanie danych modelu bez natychmiastowego zapisywania go w bazie danych. Niektóre funkcje CakePHP pobierają dane z danych Model -> $ _, a niektóre używają Model-> field(). Wynik może być zupełnie inny, co powoduje bardzo trudne do wykrycia błędy.
W krótkim
Gorąco polecam CakePHP nawet dla „dużych” stron, o ile dany model domeny pasuje na szczycie Active Record. Jeśli nie, wybierz inną strukturę.
Przepraszam, pomieszałem CakePHP z Code Igniter. Użyłem CakePHP krótko przed upuszczeniem go, ponieważ wydawało się zbyt restrykcyjne i automagiczne. –