Сохранение данных в Smalltalk/Seaside

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

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

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

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

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

Надеюсь, я не делал этого TL;DR. Огромное спасибо за понимание, которое вы, ребята Smalltalk, предоставили в моих предыдущих вопросах. Он оценил.

Ответ 1

Джастин

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

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

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

Также существуют инструменты для хранения объектов Smalltalk в современных базах данных NoSQL, таких как CouchDB, Cassandra, ТОВАРЫ или другие. Трюк здесь - это просто преобразование значений объекта Smalltalk в потоки JSON и небольшое HTTP-запрос.

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

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

Йоахим

Ответ 2

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

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

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

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

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

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

Ответ 3

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

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