IOC 컨테이너에 들어가려고하고 있는데 그 중 많은 수가 xml 구성을 사용하고 있습니다. 누구나 왜 많은 새로운 기술이 xml 구성/프로그래밍 모델 (WCF, WPF, Spring.NET, Unity, Windsor)을 향하여 움직이고 있는지에 대해 나에게 밝혀 줄 수 있습니까? XML은 복잡한 설정을 지정하기에는 좋지 않은 선택 인 것으로 보이며, 상황이 안전하고 인텔리 센스가있는 코드에서 XML을 사용하는 것이 좋습니다. 어떤 사람들은이 논증을 찾을 수도 있지만, 왜 이렇게 차가운 진보 된 기술들이 왜 XML에 의존하는지 궁금합니다.IML 컨테이너에서 xml이 눈에 띄게 나타나는 이유는 무엇입니까?
주석이 사용 된 가능성에 따라 Java 환경에서 변경된 사항이 있지만 Google Guice의 저자 Bob Lee가 I don't get Spring을 읽어야합니다.
편집 : 의견에서 언급했듯이 I was too hard on Spring...을 언급하지 않고 이전 게시물을 인용하는 것은 불공정합니다. 이제 해결되었습니다. 나를 상기시켜 줘서 고마워.
"나는 봄이 너무 어려웠다"(http://crazybob.org/2006/02/i-was-too-hard-on-spring.html)라는 그의 후속 조치를 잊지 마십시오. 그렇지만 두 구성 스타일을 모두 지원하는 DI 프레임 워크를 좋아합니다. –
사실, 나는 대답을 업데이트했다. 감사. –
.net 공간에서 다른 사람들이하는 일이기 때문입니다. 그것은 web.config로 시작했고 사람들은 그것을 확장하기 시작했습니다. 하지만 대부분의 기술은 XML 및 코드 구성을 지원합니다. 가장 큰 차이점은 구성을 변경하기 위해 응용 프로그램을 배포 할 책임이있는 시스템 관리자와 같은 비 코더 (non-coder)가 용이하다는 것입니다. 필요한 경우 XML은 여전히 내 생각에 실행 가능한 옵션입니다. 나는 XML 설정 파일에 모든 것을 넣는 대신에 .net 세계가 컨벤션으로 넘어 가기 시작하고 있다고 생각한다.
XML schema "강력하게 형식화"할 수 있습니다. 가장 인기있는 주된 이유 중 하나는 이해하기 쉽고 원하는 프로그래밍 언어로 파서 프레임 워크가 너무 많다는 것입니다. 원한다면 플랫 파일 (예 : 고정 너비 또는 CSV), INI 파일, JSON 파일 또는 사용자 정의 이진 형식을 사용하는 것을 막을 수있는 방법은 없습니다.
대부분의 큰 프레임 워크는 XML 컨텐트를 환경에 고유 한 복잡한 객체 구조로 변환하기 위해 직접적인 직렬화 방법을 사용하기 때문에 인기가 있습니다.
스키마를 강력하게 입력 할 수 있다는 것을 알고 있지만 xml의 값을 의미했습니다. 예를 들어 IOC xml의 인터페이스 이름을 잘못 입력하면 어떻게됩니까? 편집을 통해 실수를했다는 것을 즉시 알 수있었습니다. xml 구성을 사용하면 런타임에 오류가 날 것입니다. – Steve
수정하십시오. 물론 Visual Studio를 사용하는 경우 XML 편집기에 스키마 확장을 추가하여 인텔리전스 및 유형 검사를 제공 할 수 있습니다. 나는 다른 XML 편집자들도 비슷한 능력을 가지고 있다고 확신한다. –
고마워, 잘 알고있다. – Steve
IOC 및 기타 많은 "구성 가능한"기술.
XML이 문서 상호 운용성을위한 표준으로 등장한 것은 사실이었습니다.
모든 사람이 자신의 형식을 만드는 대신 모든 사람이 "새로운"형식을 채택했습니다.
잠깐 동안 좋았지 만, 결국에는 귀찮아졌습니다.
XML을 text/plain으로 재 컴파일하지 않고도 코드를 적용하여 변경 사항을 적용하려면 코드를 다시 컴파일해야하는 경우가 있습니다.
새로운 형식이 등장하고 있지만 XML과 같은 영향은 없습니다.
필자는 Unity 구성을 XML로 옮겼습니다. 코드를 다시 컴파일하지 않고도 구성을 변경할 수 있습니다. 이것은 어떤 경우에 매우 유용합니다.
그게 내가 XML을 선호하는 이유입니다. 시스템의 동작을 변경하기 위해 다시 컴파일 할 필요가 없습니다 (예 : 종속성 대체, 로깅 애스펙트 추가 등). 자바 녀석은 SpringIDE와 같은 것을 가지고 있지만 .NET에는 여전히 비슷한 것이 없다. 따라서 우리는 XSD와 UnitTests를 사용해야합니다. IMO IoC-Container는 코드에서 순전히 구성 가능하며 외부 구성 파일 (Ninject, LinFu?)을 통하지 않고 IoC의 중요한 부분이 누락되었습니다. 내 생각에, 애트리뷰트는 또한 갈 길이 아니다 : 클래스에서 의존성을 제거하는 대신 IoC 컨테이너에 의존성을 추가한다. – tobsen
동의하지만 XML 구성이 필요하지 않은 많은 작업이 있습니다.이 경우에는 Ninject를 사용하여 차가움 =을 선호합니다. – Restuta
왜 물건을 함께 붙일 때 망치가 강철 머리를 가지고 있는지 궁금합니다.
선언적 구성 파일에서 런타임에 응용 프로그램을 어셈블하는 것이 목표입니다. DI 자체는이를 구현하는 수단 일뿐입니다.
구성을 코딩 할 수 있다면 왜 IoC 프레임 워크를 사용해야합니까? 다소 긴밀하게 결합 된 디자인을 사용하고 많은 고통을 덜어줍니다.
일반적으로 mxmissile 제안 (Unity 사용)과 같이 IoC의 유창한 인터페이스가 마음에 듭니다.
이 (마 회칠이 지적했듯이) 만 개발자가 상황을 타개 할 수 있다는 것을 의미 않지만, 얼마나 자주 당신은 당신의 응용 프로그램에서 다른 하나 개의 클래스를 대체 할 수 비 개발자가 원하는 합니까? 이러한 경우 간단한 구성 대화 상자 (원하는 데이터 저장소로 백업 됨)를 준비하고 그 결과로 유창한 구성을 제어 할 수 있습니다. 이것은 취약성과 보안 문제를 방지합니다. 왜냐하면 최종 사용자가 설정 파일을 망가 뜨리면 응용 프로그램이 충돌 할 때 비난 받기 쉽기 때문입니다.
구성을 변경하기위한 주요 사용 사례는 단위 테스트를위한 것입니다. 이 경우 수동으로 가짜를 테스트 할 클래스에 수동으로 주입하거나 (보통 내가하는 일임) 유창한 구성을 다시 할 수 있습니다.
IoC 컨테이너는 IoC 디자인 패턴을 용이하게하기위한 프로그래밍 방식의 프레임 워크가 아닌 프로그래밍 방식이 아닌 응용 프로그램을 배포/구성하기위한 렌더링 엔진으로 간주되어야합니다.
따라서 XML은 두 가지 이유로 주로 사용됩니다
유창함 API는 XML 구성에 따라서도 비교할 수 없습니다, 의도 된 데이터 통합을 위해 사용하기에 매우 융통성 또한 스키마 데이터 모델의 검증 및 부족하다. 더 많은 설명은 XML in IoC containers: A Hell or a Realm을 참조하십시오.
xml에 대해 코드 완성을 사용할 수 있습니다. 예를 들어, Spring 구성 파일을위한 eclipse 플러그인이 있습니다.이 플러그인은 툴팁으로 설정된 속성의 javadoc을 보여 주며, 클래스 경로에있는 클래스 이름에 대한 자동 완성 기능을 제공하며, 해결할 수없는 모든 bean 참조를 표시합니다 현재 파일 등.
구성 파일은 실제로 응용 프로그램 구성을 나타 내기 위해 DSL 형식입니다. 이 재봉은 특정 일을보다 쉽게 표현할 수있게 해줍니다. 예를 들어 Java에서 구성 요소를 초기화 할 때 적절한 응용 프로그램 종료 (구성 요소가 depedencies 전에 종료되어야 함)를 어떻게 보장 하시겠습니까? 비즈니스 서비스 계층 주위에 인터셉터를 어떻게 구성합니까?
XML로 작성된 이유는 DSL이 필요하며 XML은 기존의 초보적인 툴체인 (편집자, 유효성 검사기, 구문 분석기 등)의 이점이 있다고 생각합니다.
XML은 XSLT 변환 결과 일 수 있으며 일반 IoC 구성 위에 사용자 지정 DSL을 이러한 방식으로 만들 수 있다고 언급 한 사람이 없습니다. 그것은 매우 강력한 접근 방법입니다.
IOC 컨테이너는 xml 구성에서 * 이동 *해야합니다. 바로 Structuremap의 방향입니다. Structuremap은 유창한 구성을 사용합니다. 다른 모든 것은 그냥 따라 잡는 것입니다. ;-) – mxmissile
@mxmissile : 개발자가 아닌 사람이 뭔가를 바꿀 때까지 좋습니다. 또한 XML 주위의 구성 툴링을 작성하고 유창한 코딩 스타일을 작성하는 것이 더 쉽습니다. –
@Whited, 나는 이해하지 못한다. 나는 손톱을 당기는 것처럼 xml을 쓰고있다. Fluent 설정은 dev의 관점에서 직관적 인 의미를 갖는 것처럼 보입니다. 또한, 비 개발자는 이런 식으로 뭔가를 만져야합니까? – Steve