나는 Google Guice as DI framework을 확인하고 있는데 약간 의아해합니다. 설정 파일이 전혀없는 이유는 무엇입니까?왜 Google Guice에 의존성 주입을위한 구성 파일이 없습니까?
this question에 대한 부분적인 설명을 찾았지만 구성 파일없이 구성 요소 역할 (또는 스위치를 사용해야하는 다른 것)을 설정할 수있는 방법이 아직 명확하지 않습니다.
도움을 주셨습니다.
구성은 많은 시나리오에 대한 올바른 결정 인 구성 파일 대신 코드에 있습니다.
예, 응용 프로그램을 배관하는 다른 방법을 해제하려면 물론 모듈을 다시 빌드해야합니다. 물론 명령 줄 인수, 속성 파일 당신이 원한다면 등.
정기적으로 응용 프로그램 배관을 변경해야하고 단일 파일 이외의 다른 파일을 다시 배포하지 않으려는 경우 Guice가 도움이되지 않을 수 있습니다. 반면에 DI를 사용하는 주요 이유가 코드를 더 명확하게 만드는 것이고, 프로덕션에서는 항상 동일한 배관을 사용하거나 Guice가 좋은 옵션입니다. 원하는 논리가 종종 있습니다. 어쨌든 배관을 분류 할 때 사용하고, 일반적으로 선언적으로 기술/구성하기 어려운 구성 요소.
서로 다른 DI 프레임 워크는 서로 다른 이점과 절충점을 가지고 있습니다. 어느 것이 든 응용 프로그램에 가장 적합한 것을 사용하십시오.
Guice의 많은 구성은 @Inject Annotation을 통해 암시 적입니다. 많은 프로젝트 복잡성은 수많은 프로젝트 유물에서 비롯됩니다. 자바 파일, Xml 파일, 속성 파일, 데이터베이스, 매개 변수 .. Guice는 설정 파일을 사용하지 않음으로써 이러한 복잡성의 일부를 제거하려고합니다.
응용 프로그램을 다시 컴파일하면 컴파일시 쉽습니다. 대부분 모듈 클래스 만 편집하면됩니다. Guice가 제공하는 대부분의 클래스는 설정이 필요 없지만 @Inject는 올바른 위치에 있습니다. 동일한 인터페이스의 두 가지 구현이있을 때만 구성해야합니다. 또는 클래스를 주입 할 때 필요합니다. Provider 클래스를 사용하는 외부 라이브러리.
대부분의 DI 구성은 배포마다 동일하므로 코드를 사용하여 Guice의 구성을 매우 간결하게 구성 할 수 있으며 컴파일 시간 유형 검사, 리팩토링 도구, 코드 탐색 등.
데이터베이스 사용자 이름 및 암호 구성과 같이 배포에서 변경 될 때까지 필요한 코드를 직접 작성할 수 있습니다. 구성 파일 (어쩌면 속성 파일)을 읽고 매개 변수를 구문 분석하고 Guice 모듈에 바인딩하여 응용 프로그램이 액세스 할 수 있도록하는 코드를 작성하십시오. 코드를 작성하는 데 필요한 코드는 많은 코드 행을 필요로하지 않습니다.
당신이 그렇게 생각한다면 구성 파일을 사용하여 부스트 랩핑을 소개하는 것은 간단합니다. 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이지만, 환경에 따라 속성 파일 속성 런타임 주입을 허용한다.
재미있는 소리 - thx – JohnIdol
그래, 내 말은 행동을 바꾸는 유일한 방법은 모든 것을 재건하는 것이다. – JohnIdol