Utrwalanie danych w Smalltalk/Seaside

Question

Ostatnio spędziłem trochę czasu na zapoznawaniu się z programem Smalltalk and Seaside. Pochodzę ze świata Java EE i jak możesz sobie wyobrazić, że trudno mi było opanować niektóre z koncepcji Smalltalk. :)

W tej chwili staram się zrozumieć, w jaki sposób upowszechnianie danych jest najczęściej realizowane w świecie Smalltalk. Założeniem dla mnie jako programisty Java jest użycie RDMS (tj. MySQL) i ORM (tj. Hibernacja). Rozumiem, że tak nie jest w przypadku Smalltalk (przynajmniej przy użyciu Hibernate). Niekoniecznie szukam metody, która jest najbardziej zbliżona do sposobu, w jaki odbywa się to w Java EE.

Czy najczęściej zapisuje się dane w obrazie, magazynie obiektów lub RDMS? Czy korzystanie z RDMS jest nawet typowe dla aplikacji Smalltalk?

Rozumiem, że nie ma tu jednego uniwersalnego podejścia, a odpowiednia strategia utrzymywania będzie zależeć od potrzeb aplikacji (ile danych, współbieżność itp.). Jakie jest dobre podejście, które może zacząć się proste, ale także skalować?

Oglądałem video Avi Bryant, omawiając strategię, której używał do wytrwałości i skalowania DabbleDB. Z tego co rozumiem, dane klienta zostały zapisane bezpośrednio w obrazie (jeden obraz na klienta). To działało w jego przypadku użycia, ponieważ klienci nie musieli udostępniać danych. Czy to jest wspólne podejście?

Mam nadzieję, że nie zrobiłem tego TLDR. Wielkie dzięki dzięki wnikliwościom, które przedstawiliście w poprzednich pytaniach. Jest to doceniane.

Answer 1

Justin,

nie martw się, Smalltalk nie jest tak inna forma innych językach, w tym obszarze, to po prostu dodaje opcję utrwalania obrazu opiera.

Istnieją odwzorowania O/R, takie jak Hibernacja dla Smalltalk, GLORP i jego port Pharo DBXtalk są z pewnością najbardziej popularne w dzisiejszych czasach. Powinny one być dla ciebie bardzo wygodne, jeśli znasz Hibernate.

Są też rozwiązania OODB, takie jak GemStone lub Magma DB lub VOSS i wiele innych, które pozwalają pozostawić wszystkie problemy związane z mapowaniem O/R. Większość z nich ogranicza się do przechowywania obiektów Smalltalk, a GemStone stanowi wyjątek w dostarczaniu mostów do Rubiego i innych języków.

Istnieją również narzędzia do przechowywania obiektów Smalltalk w nowoczesnych bazach danych NoSQL, takich jak CouchDB, Cassandra, GOODS lub inne. Sztuką jest tutaj tylko konwersja wartości obiektów Smalltalk na strumienie JSON i trochę żądania HTTP.

Wreszcie istnieje opcja zapisania pełnego obrazu Smalltalk. Powiedziałbym, że możesz to zrobić w środowisku produkcyjnym, ale nie jest to standardowy lub preferowany sposób, aby go dong dla wielu ludzi. Robisz to dużo w rozwoju, ponieważ możesz po prostu zapisać obraz i wznowić swoją pracę następnym razem dokładnie z wszystkimi obiektami w miejscu, jakie miałeś, kiedy je zapisałeś.

Podstawowa linia to: Wszystkie dostępne opcje pamięci są również dostępne w Smalltalk plus jeden dodatkowy.

Joachim

Answer 2

Myślę, że to po prostu zależy od tego jak duża jest Twoja DB ma być i jakie obciążenia będzie manipulowaniu.

W moim przypadku wszystkie aplikacje, które napisałem, używają funkcji perswazji dysku z serializacją dysku. Zasadniczo wystarczy serializować obiekty, używając paliwa na żądanie.W moim przypadku robię to za każdym razem, gdy przetwarza się ważne dane, a także regularny proces, który tworzy je cyklicznie co 24 godziny. Obraz jest również automatycznie zapisywany co 24 godziny.

Największą aplikacją, jaką napisałem przy użyciu tego podejścia, jest obsługa wszystkich procesów biznesowych małej firmy złożonej z 10 pracowników oraz około 50 freelancerów, którzy używają jej codziennie przez półtora roku. Obciążenie jest dość "duże", biorąc pod uwagę, że aplikacja zajmuje się dużymi plikami przez cały czas, ale aplikacja pozostała stabilna i szybka. Przejście na nowy serwer i aktualizowanie obrazu Pharo było tak proste, jak odzyskanie projektu z Monticello i zmaterializowanie najnowszej serializowanej "bazy danych".

Moim zdaniem ORM to niepotrzebny ból, jesteśmy w świecie przedmiotów, a spłaszczanie naszych obiektów jest po prostu złe, zwłaszcza, gdy mamy ładne, zorientowane obiektowo rozwiązania.

Tak więc, jeśli Twoja aplikacja obsługuje dość małe ilości danych, proponuję albo moje proste podejście, albo SandstoneDB. Jeśli Twoja aplikacja obsługuje ogromne ilości transakcji i danych, wybrałbym Gemstone.

Tylko moje dwa centy.

Answer 3

Ramon Leon opisuje sytuację, podstawowe strategie i ich kompromisy pięknie in his blog post.

Zacznę od jego prostego systemu opartego na obrazach, który I ported i wykorzystania w Pharo 1.3. Mariano Martinez Peck ostatnio zaadaptował go do użycia paliwa (ten sam link). To bardzo proste, wykonuje zadanie i daje mi dużo więcej pewności siebie, aby grać na moim wizerunku, wiedząc, że nawet jeśli trwale go uszkodzę, wszystkie moje dane są bezpieczne. Po prostu kopiuję foldery danych do nowego folderu obrazów, ładuję moje pakiety i wszystkie moje obiekty są żywe w nowym obrazie.