Постоянство данных в Smalltalk / Seaside - PullRequest
18 голосов
/ 01 декабря 2011

В последнее время я проводил некоторое время, знакомясь с Smalltalk и Seaside. Я из мира Java EE, и, как вы можете себе представить, мне было сложно разобраться в некоторых концепциях Smalltalk. :)

В данный момент я пытаюсь понять, как постоянство данных наиболее типично реализуется в мире Smalltalk. Для меня, как для программиста на Java, предполагается использовать RDMS (т.е. MySQL) и ORM (например, Hibernate). Я понимаю, что это не относится к Smalltalk (по крайней мере, с использованием Hibernate). Я не обязательно ищу метод, который наиболее точно соответствует тому, как это делается в Java EE.

Чаще всего данные хранятся в изображении, хранилище объектов или RDMS? Типично ли для приложений Smalltalk использование RDMS?

Я понимаю, что здесь не существует универсального подхода, и правильная стратегия сохранения будет зависеть от потребностей приложения (объем данных, параллелизм и т. Д.). Какой хороший подход, который может начинаться с простого, но также масштабируемого?

Я смотрел видео , в котором Ави Брайант рассказывал о стратегии, которую он использовал для сохранения и масштабирования DabbleDB. Из того, что я понимаю, данные клиента были сохранены прямо в изображение (одно изображение на клиента). Это работало в его случае использования, так как клиенты не должны были обмениваться данными. Это общий подход?

Надеюсь, я не сделал этот TLDR. Большое спасибо за понимание, которое вы, ребята из Smalltalk, предоставили в моих предыдущих вопросах. Это ценится.

Ответы [ 3 ]

13 голосов
/ 01 декабря 2011

Джастин,

не волнуйтесь, Smalltalk не так уж отличается от других языков в этой области, он просто добавляет опцию персистентности на основе изображений.

Существуют такие схемы отображения O / R, какHibernate для Smalltalk, GLORP и порт Pharo DBXtalk, безусловно, являются самыми популярными в наши дни.Если вы знакомы с Hibernate, вам это будет очень удобно.

Тогда есть решения OODB, такие как GemStone, Magma DB или VOSS и многие другие, которые позволяют вам оставить позади все проблемы с O / R-отображением.Большинство из них довольно ограничены хранением объектов Smalltalk, GemStone является исключением в предоставлении мостов для Ruby и других языков.

Существуют также инструменты для хранения объектов Smalltalk в современных базах данных NoSQL, таких как CouchDB, Cassandra, GOODS или других.Хитрость здесь заключается в преобразовании значений объекта Smalltalk в потоки JSON и небольшом HTTP-запросе.

Наконец, есть возможность сохранить ваше полное изображение Smalltalk.Я бы сказал, что вы можете сделать это в производственной среде, но для многих это не стандартный или предпочтительный способ.Вы делаете это много в разработке, потому что вы можете просто сохранить изображение и возобновить работу в следующий раз точно со всеми объектами на месте, как они были у вас при сохранении.

Итак, основная строка: Всеварианты хранения, которые вы знаете, доступны и в Smalltalk, плюс одно дополнительное.

Иоахим

9 голосов
/ 01 декабря 2011

Полагаю, это в основном зависит от того, насколько большой будет ваша БД, и какую нагрузку она будет обрабатывать.

В моем случае все приложения, которые я когда-либо писал, используют постоянство образа с сериализацией диска.По сути, вы просто сериализуете свои объекты, используя Fuel по запросу.В моем случае, я делаю это каждый раз, когда рассматривается важная часть данных, плюс регулярный процесс, который сериализует их каждые 24 часа.Изображение также автоматически сохраняется каждые 24 часа.

Самым большим приложением, которое я написал с использованием этого подхода, является обработка всех бизнес-процессов небольшой компании из 10 человек плюс около 50 фрилансеров, которые используют его каждый день дляполтора года.Рабочая нагрузка довольно большая, учитывая, что приложение постоянно работает с большими файлами, но приложение остается стабильным и быстрым.Переключиться на новый сервер и обновить образ Pharo так же просто, как вернуть проект из monticello и материализовать последнюю сериализованную «базу данных».

По моему мнению, ORM - это ненужная боль, мы находимся вобъектный мир, и необходимость выравнивать наши объекты кажется неправильной, особенно когда у нас есть хорошие объектно-ориентированные решения.

Итак, если ваше приложение обрабатывает довольно небольшие объемы данных, я бы предложил либо мой простой подход, либоSandstoneDB.Если ваше приложение имеет дело с огромным количеством транзакций и данных, я бы пошел Gemstone.

Только мои два цента.

7 голосов
/ 01 декабря 2011

Рамон Леон прекрасно описывает ситуацию, основные стратегии и их компромиссы в своем посте в блоге .

Я бы начал с его простой среды, основанной на постоянстве изображений, которую я перенес. и использовать в Pharo 1.3.Мариано Мартинес Пек недавно адаптировал его для использования топлива (та же ссылка).Это очень просто, делает работу и дает мне гораздо больше уверенности, чтобы играть в свой имидж, зная, что даже если я навсегда испорчу его, все мои данные в безопасности.Я просто копирую папки с данными в новую папку с изображениями, загружаю свои пакеты, и все мои объекты живы в новом образе.

...