Почему нет никакого конфигурационного файла вообще для внедрения зависимости с Google Guice?
Вы можете обернуть массив в анонимный класс . Одноразовое использование, как это, является основной причиной их существования.
$result = new class {
private $data = array
(
array("name"=>"Toby", "q1"=>"1"),
array("name"=>"Phelps", "q1"=>"1"),
array("name"=>"Davies", "q1"=>"1"),
array("name"=>"Keith", "q1"=>"1"),
);
private $data_index = 0;
public $num_rows;
public function __construct() {
$this->num_rows = count($this->data);
}
public function fetch_assoc() {
if (isset($this->data[$this->data_index])) {
$index = $this->data_index++;
return $this->data[$index];
}
}
};
6 ответов
Конфигурация находится в коде вместо файлов конфигурации, что является допустимым решением для многих сценариев.
Да это означает, что вам нужно пересобрать (возможно, только модули), если вы хотите использовать другой способ подключения вашего приложения - хотя, конечно, вы можете получить некоторые значения конфигурации из аргументов командной строки, файлов свойств и т. д., если хотите .
Если вам регулярно нужно менять сантехнику приложения и не хотите повторно развертывать что-либо, кроме одного файла, Guice может не подойти вам. Если, с другой стороны, ваша основная причина использования DI состоит в том, чтобы сделать ваш код более понятным, и в производстве вы всегда будете использовать одну и ту же систему слежения (или достаточно близко), тогда Guice - хороший вариант - часто вам нужны кусочки логики использовать при сортировке сантехники в любом случае,
Большая часть конфигурации DI будет одинаковой от одного развертывания к другому, поэтому их очень легко настроить с помощью кода , что делает конфигурацию Guice очень лаконичной, и вы получаете преимущества проверки типов времени компиляции, инструментов рефакторинга, навигации по коду и т. д.
Для тех немногих вещей, которые меняются от развертывания к другому, таких как конфигурация имени пользователя и пароля базы данных, вы можете написать нужный код самостоятельно. Напишите код, который читает файл конфигурации (возможно, файл свойств), анализирует параметры и связывает их в ваших модулях Guice, чтобы ваше приложение получало к ним доступ. Код, необходимый для этого, не займет много строк кода.
Большая часть конфигурации в Guice неявна через аннотацию @Inject. Большая сложность в проектах связана с большим количеством проектных артефактов. Java-файлы, Xml-файлы, файлы свойств, базы данных, параметры. Guice пытается удалить часть этой сложности, не используя конфигурационные файлы.
Перемонтировать приложение легко во время компиляции. Скорее всего, вам нужно всего лишь отредактировать класс вашего модуля. Для большинства классов, управляемых Guice, вам вообще не понадобится конфигурация, а только @Inject в нужных местах - вам нужно будет что-либо конфигурировать только тогда, когда у вас есть две разные реализации одного и того же интерфейса - или когда вы хотите внедрить классы из внешние библиотеки с использованием классов Provider.
Не уверен, что вы подразумеваете под файлом, но Guice позволяет вам изменять реализации через Binder и custom Поставщики .
Если вы так склонны, вводить усиление с использованием файлов конфигурации - тривиально. Мы используем Guice вместе с простым API, который загружает файлы свойств туда, где действительно нужно параметризовать вещи. Это можно использовать вместе с аннотациями @Named и т. Д., И, конечно, вы можете иметь некоторые условные выражения в модулях (хотя лучше не переусердствовать).
Это пример того, как часть нашей начальной загрузки настроен:
public class MetModules extends AbstractModule {
private static final Logger log = LoggerFactory.getLogger(MetModules.class);
private final Settings settings;
public MetModules(Settings settings) {
this.settings = settings;
}
@Override
protected void configure() {
// common (stage independent modules) go here
install(new CommandsModule());
install(new ServletsModule());
install(new DataBaseModule(settings));
install(new JobsModule(settings));
// any development/ production specific modules
Stage stage = currentStage();
if (Stage.DEVELOPMENT.equals(stage)) {
configureForDevelopment();
} else { // PRODUCTION
configureForProduction();
}
}
/**
* Install modules that will be used in development.
*/
private void configureForDevelopment() {
// Mock implementation of email delivery that just logs it got a
// message rather than trying to send it.
install(new AbstractModule() {
@Override
protected void configure() {
bind(Delivery.class).toInstance(new Delivery() {
public String deliver(MailMessageExchange exchange)
throws DeliveryException {
log.info("email message: "
+ exchange.getMessage().getMailMessage()
+ " to "
+ Arrays.asList(exchange.getMessage()
.getMailMessage().getTo())
+ " (not sent)");
return "fooMessageId";
}
});
}
});
// local in-memory registry suffices
install(new LocalServiceRegistryModule());
// local in memory db implementations of services
install(new LocalServicesModule());
}
/**
* Install modules that will be used in production.
*/
private void configureForProduction() {
// we really only need this (error interception and audit logging)
// in production
install(new AopModule());
install(new ZooKeeperServiceRegistryModule()); }
}
Где Параметры - это то, что читает наши файлы свойств и тому подобное. Прямо сейчас разработка / производство вместе с определенными переопределениями настроек, характерными для развертываний, похоже, делают эту работу за нас,
Недавно я создал следующий проект.
http://code.google.com/p/guice-property-injector/
Это WIP, но позволяет внедрять свойства из файла свойств во время выполнения в зависимости от среды.