Dlaczego? Jest znacznie prościej niż ręczne dodawanie najpierw kolumn w bazie, a potem pól w klasach. hibernate.hbm2ddl.auto=update
i jedziemy.
IMO, szybciej jest użyć narzędzia GUI do generowanie kolumn np. dla PostgreSQL jeśli od początku chcę zaprojektować całą bazę lub grupę tabel niekoniecznie powiązanych z obecnymi strukturami.
http://www.sqlpower.ca/page/architect-demos
Czy jak rozwijasz dużą aplikację code-first od początku zaczynasz od utworzenia klasy? Następnie dodajesz do niej odpowiednie adnotacje? Czy masz do tego odpowiedniej jakości narzędzie GUI, które powoduje, że nie musisz ręcznie pisać tego kodu, w którym widzisz relacje między tabelami, tak jak widać tabele na diagramie ERD. Czy to narzędzie GUI pokazuje od razu relacje między tabelami, które zostaną wygenerowane? Z jakiego IDE korzystasz tak, aby wygodnie generować code-first w JPA, najlepiej graficznie, bo IMO nieprzyjemne jest klepanie encji, a każda z nich ma z reguły kilkanaście linii kodu. Chyba nie opłaca się robić to ręcznie z wyjątkiem drobnego dostosowania do własnych potrzeb.
Większym problemem jest zazwyczaj konieczność aktrualizacji procedur, funkcji, "native sql" i innych tego typu wynalazków. Dlatego we wszystkich projektach, które realizowalem używaliśmy dualnego podejścia.
To zawsze będzie problemem. Ale jak odpowiednio zarządza się zmianami to nie ma problemu.
W pierwszym kroku dodawaliśmy pole w klasie i to silnik ORM aktualizował strukturę bazy deweloperskiej.
Bawiłem się w podobny sposób programując mały projekt w GRails i było to efektywne. Ale jakoś wole najpierw zaprojektować bazę.
Następnie aktualizowane były procedury, triggery, itp. rzeczy
W czasie wdrożenia przygotowujemy skryp aktualizujacy tabelę i inne elmenty i jest on odpalany. Na poziomie produkcji używamy `hibernate.hbm2ddl.auto=validate`. Dzięki temu mamy szybką modyfikację baz developerskich i bezpieczną modyfikację produkcji.
Ja bezpieczniej się czuje, gdy wykonuje ręcznie odpowiedni DDL najpierw na maszynie deweloperskiej, a następnie produkcyjnie.
Z drugiej strony kiedyś na pewno muszę spróbować entity-first, bo czegoś nowego się nauczę. Code-first wydaje mi się to nienaturalne w projektowaniu relacyjnych baz danych, które są wręcz stworzone tak, aby myśleć o nich jako o tabelach, a nie encjach.
Zgadzam się, że jak dodaje np. dodatkową tabelkę to pomoc ORMa może nie zaszkodzić, jednak ALTER TABLE x ADD COLUMN y to też nie jest aż taki straszny problem.