2011-01-18 8 views
5

Pracuję nad rozszerzeniem istniejącej aplikacji PHP. Niestety dla mnie obecna aplikacja to bałagan. To wszystko kod spaghetti z surowymi wywołaniami mysql_ *. Jęk. Nie ma mowy, żebym to zrobił w częściach, które poszerzam.Potrzebujesz prostego narzędzia ORM lub DBAL dla istniejącej aplikacji PHP

Poszukuję prostego ORM DBAL, który mogę łatwo wpuścić i zacząć używać. Żądane funkcje:

  • Musi działać na istniejącym schemacie bazy danych. Najlepiej przy minimalnej lub żadnej dodatkowej konfiguracji. Istniejący schemat bazy danych ma taką samą jakość jak istniejący kod PHP (brak rozsądnych konwencji nazewnictwa, nie jest znormalizowany itp.). Nie chcę poświęcać dni na ręczne przekształcanie schematu bazy danych w właściwości adnotowanych obiektów a la Doctrine 2.
  • Musi być w stanie pracować równolegle z istniejącymi surowymi zapytaniami mysql_ *. Nie mam pojęcia, jak nawilżające ORM, takie jak Doctrine 2 lub Propel, zachowują się, gdy skrypty ręcznie manipulują danymi w bazie danych za ich plecami, ale zakładam, że nie jest ładna.
  • Musi działać na PHP 5.2.x. Chciałbym kochać używać PHP 5.3, ale nie mam żadnego interesu w przeglądaniu istniejących 125K wierszy kodu spaghetti, aby upewnić się, że działa on na PHP 5.3.
  • Relacje nie są wymagane. W kilku miejscach potrzebuję danych relacyjnych, z chęcią zadzwonię na dodatkowe find() lub query() lub cokolwiek samemu.
  • Punkty premiowe, jeśli ma obsługę niektórych wyzwalaczy (np. beforeSave, afterSave). Nie jest to wymaganie, ale po prostu przyjemne.

Edytuj: Ktoś wyrzucił mnie z mojej nędzy. Właśnie dowiedziałem się, że linie 125K kodu spaghetti zmieniają również schemat bazy danych. Np. Dodaj gdzieś dodatkową opcję i zacznij latać cały szereg instrukcji ALTER TABLE. Mogłabym prawdopodobnie wypełnić roczną wartość TheDailyWTF z tą bazą kodu. Jeszcze jedno wymaganie:

  • Musi być w stanie poradzić sobie automatycznie ze zmieniającym się schematem bazy danych (np. Dodając kolumny).

Szukałem kilku rozwiązań, ale nie jestem pewien, jak dobrze by one działały, biorąc pod uwagę wymagania. Doctrine 2, RedBeanPhp i tym podobne wymagają PHP 5.3, więc nie działają. Istnieje starsza wersja RedBeanPhp dla PHP 5.2.x, ale nie wiem, czy działałaby z niechlujnym, istniejącym schematem bazy danych. Notorm wygląda dobrze, jeśli chodzi o pobieranie danych, ale nie wiem, czy można go skonfigurować dla istniejącego schematu bazy danych i jak łatwo można przywrócić dane do bazy danych.

Idealnie chciałbym coś prostego. Np:

$user = User::find($id); 
$user->name = 'John Woo'; 
$user->save(); 

Lub:

$articles = ORM::find('article')->where('date' => '2010-01-01'); 
foreach ($articles as $article) { 
    echo $article->name; 
} 

Wszelkie wskazówki lub nawet alternatywne rozwiązania są mile widziane!

Odpowiedz

9

używam ... http://github.com/j4mie/idiorm/

ma aktywną realizację rekordowy zbyt w postaci Paryżu.

Co do edytowania.Idiorm radzi sobie ze zmieniającymi się schematami, a składnia prawie dokładnie odpowiada typowi, który chcesz zadać w pytaniu.

+1

Od kilku tygodni używam Idiorm i Paris w aplikacji i bardzo to lubię! –

1

Jak dobrze zaglądałeś do Doctrine? Używam Doctrine 1.2 do takich rzeczy. Dość łatwa w konfiguracji, pozwala rozpocząć od istniejącego schematu. Automatycznie oblicza relacje między tabelami, które mają ograniczenia klucza obcego.

Posiada rozbudowane wsparcie dla wyzwalaczy i zachowań, dzięki czemu można również wydać punkty premiowe i ma również wsparcie relacyjne, więc dodatkowe zapytania nie są konieczne. Ma piękny leniwy ładunek i jest wyposażony w elastyczny język zapytań (zwany DQL), który pozwala na wykonanie prawie dokładnie tych samych rzeczy, które można wykonać w SQL tylko w ułamku wysiłku.

Wasz przykład będzie wyglądać następująco:

/* To just find one user */ 
$user = Doctrine::getTable('User')->findOneById($id); 

/* Alternative - illustrating DQL */ 
$user = Doctrine_Query::create() 
    ->from('User u') 
    ->where('u.id = ?',array($id)) 
    ->fetchOne(); 

$user->name = 'John Woo'; 
$user->save(); 

To musi być w stanie współpracować z istniejącymi surowy mysql_ * zapytaniami. Nie mam pojęcia, jak nawilżające ORM, takie jak Doctrine 2 lub Propel, zachowują się, gdy skrypty ręcznie manipulują danymi w bazie danych za ich plecami, ale zakładam, że nie jest ładna.

To jest technicznie niemożliwe do automatycznego zarządzania; Baza danych SQL po prostu nie przesyła rzeczy do ORM, więc aby zaktualizować rzeczy, które zostały zmienione w tle, należy wykonać dodatkowe zapytanie w jedną lub w drugą stronę. Na szczęście Doctrine bardzo ci to ułatwia:

/* @var User $user */ 
/* Change a user using some raw mysql queries in my spaghetti function */ 
$this->feedSpaghetti($user->id); 

/* Reload changes from database */ 
$user->refresh(); 
+0

Ale co się dzieje, gdy jakaś inna część aplikacji, wciąż używająca surowych wywołań mysql_ *, zmienia dane z tyłu Doctrine? Lub gorzej, kiedy schemat zmienia się pod jego stopami? Tak jak powiedziałem, aplikacja ma kod 125K spaghetti z poważnie zdenormalizowaną bazą danych. Załóż najgorsze. Pomnóż przez czynnik 2. Czy Doctrine sobie z tym poradzi? –

+0

Nie jestem pewien, czy przeczytałeś już moją aktualizację. Musisz odświeżyć rekord, ale hej, ze względu na naturę SQL, będzie tak w każdym ORM-ie. Jeśli boisz się, że rekord Doctrine stanie się nieaktualny, po prostu odśwież go, a jego wartości pól zostaną ponownie pozyskane z bazy danych. –

Powiązane problemy