응용 프로그램에서 DI를 사용해야하는 유즈 케이스가 확실하지 않습니다. PlaceService 또는 CalculationService 등의 주입 서비스는 매우 적합하지만 DI 객체를 User과 같이 만들어야합니까? User에 성 및 이름이 필요한 생성자가 하나만있는 경우 무엇입니까? DI로 해결할 수 있습니까?DI의 사용 패턴/사용 사례 또는 사용 시작시기
DI를 사용하여 설정/목록 인터페이스 용 인스턴스를 만들어야합니까, 아니면이 과잉 잔인합니까?
저는 주로 guice를 사용합니다.
일반적으로 내가 사용하는 규칙은 객체가 순전히 원시 값으로 구성 될 수 있고 객체가 다른 구현으로 대체 될 수있는/최소의 기회가없는 경우를 제외하고는 일반적으로 종속성 주입을 선호합니다.
도메인 객체의 경우, 특히 객체가 anemic domain model이 아닌 경우, 즉 객체가 getter 및 setter의 봉지 인 경우에는 객체를 데이터 저장소에 유지하는 것이 유용 할 수 있습니다 등등 객체의 종류의 경우, 의존성 주입과 Salve 강력한 조합이 될 수 있습니다.
guice는 User 객체 (AssistedInject)와 같은 객체에서 발생하는 문제 유형에 대한 특정 솔루션을 제공합니다. 다른 가벼운 컨테이너 또는 빌더 또는 어댑터 패턴을 사용하여 유사한 작업을 수행 할 수도 있습니다.
ig0774의 대답은 좋은 출발점입니다. 기관 또는 값 객체에 대한 서비스에 대한 Domain-Driven Design의 용어, 당신이해야 DI에서
있지만 : 또한, 나는 엄지 손가락의 규칙을 제공하고 싶습니다.
즉, DI는 일반적으로 하나 또는 알려진 숫자가 사용되는 개념적으로 수명이 긴 상태 비 저장 객체에 적합합니다.
+1 추가 안내는 내 대답을 참조하십시오. –