Sprawdzam Google Guice as DI framework, ale jestem trochę zdziwiony: dlaczego w ogóle nie ma pliku konfiguracyjnego?Dlaczego w Google Guice nie ma pliku konfiguracyjnego na zastrzyk zależności?
Znalazłem częściowe wyjaśnienie na this question, ale nadal nie jest jasne, w jaki sposób byłbym w stanie ustawić moje role składników (lub jakiejkolwiek innej rzeczy, której potrzebuję użyć przełącznika) bez pliku konfiguracyjnego.
Każda pomoc doceniona!
Konfiguracja jest w kodzie zamiast w plikach konfiguracyjnych, co jest ważną decyzją dla wielu scenariuszy.
Tak, oznacza to, że musisz przebudować (prawdopodobnie tylko moduły), jeśli chcesz udostępnić inny sposób instalowania aplikacji - mimo że oczywiście możesz uzyskać wartości konfiguracyjne z argumentów wiersza poleceń, plików właściwości itd. jeśli chcesz.
Jeśli regularnie zmieniasz system hydrauliczny aplikacji i nie chcesz przenosić niczego poza jednym plikiem, Guice może nie być dla Ciebie. Jeśli z drugiej strony głównym powodem używania DI jest uczynienie kodu bardziej klarownym, a podczas produkcji zawsze będziesz używał tej samej kanalizacji (lub wystarczająco blisko), wtedy Guice jest dobrym rozwiązaniem - często są to elementy logiki, które chcesz do wykorzystania podczas sortowania instalacji i tak i komponentów, które są ogólnie trudne do opisania/konstruktywnie deklaratywnie.
Różne schematy DI mają różne zalety i kompromisy - użyj tego, który jest najbardziej odpowiedni dla twojego zastosowania.
Wiele konfiguracji w Guice jest implicite, za pomocą adnotacji @Inject. Duża złożoność projektów pochodzi z dużej liczby artefaktów projektu. Pliki Java, pliki Xml, pliki właściwości, bazy danych, parametry. Guice próbuje usunąć część tej złożoności, nie używając plików konfiguracyjnych.
Ponowne okablowanie aplikacji jest łatwe w czasie kompilacji. Najprawdopodobniej będziesz musiał tylko edytować swoją klasę modułów. Dla większości klas opracowanych przez Guice, nie potrzebujesz żadnej konfiguracji, ale tylko @Inject we właściwych miejscach - będziesz musiał tylko skonfigurować wszystko, gdy masz dwie różne implementacje tego samego interfejsu - lub gdy chcesz wstrzyknąć klasy z biblioteki zewnętrzne korzystające z klas dostawców.
Większość konfiguracji DI będzie taka sama, od jednego wdrożenia do drugiego, więc można je bardzo dobrze skonfigurować za pomocą kodu, co sprawia, że konfiguracja Guice jest bardzo zwarta i uzyskuje się korzyści z kontroli typu kompilacji, narzędzi do refaktoryzacji, kodu Nawigacja itp.
Dla tych kilku rzeczy, które zmieniają się z wdrożenia na inne, takie jak nazwa użytkownika bazy danych i konfiguracja hasła, możesz samodzielnie napisać potrzebny kod. Napisz kod, który odczytuje plik konfiguracyjny (może plik właściwości), analizuje parametry i łączy je w modułach Guice, aby Twoja aplikacja uzyskała do nich dostęp. Kod potrzebny do tego nie zajmie wielu linii kodu.
Wprowadzanie doładowań za pomocą plików konfiguracyjnych jest bardzo proste, jeśli jesteś tak pochłonięty. Używamy Guice razem z prostym interfejsem API, który ładuje pliki właściwości tam, gdzie dzieje się coś, co naprawdę wymaga sparametryzowania. To może być używane razem z @Name adnotacjami i takimi, i oczywiście możesz mieć pewne warunkowe moduły (choć dobrze jest nie nadużywać tego).
Jest to przykład tego, jak część naszej ładowania początkowego jest ustawiony:
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()); }
}
Gdzie Ustawienia to co czyta nasze pliki właściwości i takie. W tej chwili rozwój/produkcja wraz ze specyficznymi zmianami ustawień specyficznymi dla wdrożeń wydaje się wykonywać dla nas zadanie, ale moglibyśmy pójść dalej z tym, gdybyśmy chcieli oczywiście.
Niedawno utworzyłem następujący projekt.
http://code.google.com/p/guice-property-injector/
Jest WIP ale pozwala zastrzyk wykonania właściwości z pliku własności w oparciu o środowisko.
Brzmi interesująco - thx – JohnIdol
Tak, mam na myśli to, że jedynym sposobem na zmianę zachowania jest odbudowanie całości. – JohnIdol