Как хранить данные за пределами Pharo Smalltalk? [Дубликат]
У меня есть другая перспектива ответить на это.
При работе на разных уровнях, например, в приложении MVC, контроллеру нужны службы для вызова бизнес-операций. В таких сценариях контейнер инжекции зависимостей может использоваться для инициализации служб, чтобы исключить исключение NullReferenceException. Это означает, что вам не нужно беспокоиться о проверке нулевого значения и просто вызвать службы с контроллера, как будто они всегда будут доступны (и инициализированы) как одиночный или прототип.
public class MyController
{
private ServiceA serviceA;
private ServiceB serviceB;
public MyController(ServiceA serviceA, ServiceB serviceB)
{
this.serviceA = serviceA;
this.serviceB = serviceB;
}
public void MyMethod()
{
// We don't need to check null because the dependency injection container
// injects it, provided you took care of bootstrapping it.
var someObject = serviceA.DoThis();
}
}
3 ответа
Джастин,
не волнуйтесь, Smalltalk не так отличается от других языков в этой области, он просто добавляет параметр сохранения на основе изображения.
Есть O / R Mappers, такие как 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, плюс один дополнительный.
Йоахим
-
1– Stephan Eggermont 11 November 2013 в 15:36
-
2– Joachim Tuchel 7 January 2014 в 22:20
Я предполагаю, что это в основном зависит от того, насколько большой будет ваша БД, и какую нагрузку он будет обрабатывать.
В моем случае все приложения, которые я когда-либо писал, используют устойчивость изображения с сериализацией диска. По сути, вы просто сериализуете свои объекты, используя Fuel по запросу. В моем случае я делаю это каждый раз, когда рассматривается важная часть данных, а также регулярный процесс, который сериализует их каждые 24 часа. Изображение также автоматически сохраняется каждые 24 часа.
Самое большое приложение, которое я написал с помощью этого подхода, - это обработка всех бизнес-процессов небольшой компании из 10 сотрудников плюс около 50 фрилансеров, которые ее использовали каждый день на полтора года. Рабочая нагрузка довольно «большая», учитывая, что приложение работает с большими файлами все время, но приложение остается стабильным и быстрым.
На мой взгляд, ORM - это ненужная боль, мы находимся в объектный мир и необходимость сглаживания наших объектов чувствует себя просто неправильно, особенно когда у нас хорошие объектно-ориентированные решения.
Итак, если ваше приложение обрабатывает довольно небольшие объемы данных, я бы предложил либо мой простой подход или SandstoneDB. Если ваше приложение имеет дело с огромным количеством транзакций и данных, я бы пошел Gemstone.
Только мои два цента.
Рамон Леон описывает ситуацию, основные стратегии и их компромиссы красиво в своем сообщении в блоге .
Я бы начал с его основы на основе простейшего изображения, которая I портировано и используется в Pharo 1.3. Мариано Мартинес Пек недавно адаптировал его для использования Fuel (та же ссылка). Это очень просто, делает работу и дает мне больше уверенности в том, чтобы играть на моем изображении, зная, что даже если я навсегда нанесу вред, все мои данные в безопасности. Я просто копирую папки данных в новую папку изображений, загружаю свои пакеты, и все мои объекты живы в новом изображении.