1
저는 약 200 개의 프로젝트로 구성된 거대한 .NET 솔루션을 계승했습니다. 이제는 자신의 구성 요소를 우리의 응용 프로그램에 추가하기를 원하는 일부 개발자가 있습니다. API를 통해 기능을 노출하기 시작할 필요가 있습니다.버전 독립성을위한 적절한 API 디자인?
물론 우리가 손에 쥐고있는 솔루션에는 거미줄 같은 의존성이 포함되어 있으므로 어딘가에 사소한 변경이있을 때마다 API를 방해하지 않도록 조심해야합니다 앱. 이전 타사 앱을 손상시키지 않으면 서 새 기능을 점진적으로 노출 할 수 있기를 바랍니다.
이 문제를 해결할 방법이 있지만 이상적인 방법인지는 확실하지 않습니다. 다른 아이디어를 찾고있었습니다.
내 계획에는 본질적으로 3 개의 dll이 있습니다.
- APIServer_1_0.dll - 이것은 모든 종속성과 DLL 될 것이다.
- APIClient_1_0.dll - 개발자가 실제로 언급하는 dll입니다. 우리 솔루션의 혼란에 대한 언급이 없습니다.
- APISupport_1_0.dll - 클라이언트 부분이 "서버"구성 요소를 동적으로로드하고 필요한 모든 기능을 수행 할 수있는 인터페이스가 포함됩니다. 위의 dll은 모두 이것에 의존합니다. 그것은 "클라이언트"부분을 참조하는 유일한 dll 것입니다. 우리는 윈도우 서비스 사이의 프로세스 간 통신을하는 방식이 (오히려 동적으로로드 DLL을보다 명명 된 파이프를 통해 서버에 클라이언트 회담 것을 제외) 종류의 유사하기 때문에
나는 처음에이 디자인에 도착했다.
나는이 작업을 할 수 있다고 확신하지만 동일한 작업을 수행하는 더 좋은 방법이 있는지 알고 싶어합니다.
작업을 설명하지 않았습니다. 어떤 종류의 플러그인 아키텍처는 의존성을 추적하는 것을 어렵게 만듭니다. 너 더 나빠질거야. –
@ 한스 - 내가 더 나빠질거야? 전체 코드 기반을 배포하고 싶지는 않습니다. 따라서 개발자는 모든 의존성을 해결할 수 있습니다.제안 된 솔루션으로 이전 버전의 기능을 손상시키지 않으면 서 새 버전을 추가 할 수 있습니다. 나는 의존성을 전혀 추적 할 필요가 없다. 개발자는 API 버전을 선택하고 빌드하며 원하지 않는 경우 다시 빌드해야하지 않아야합니다. – Justavian
이러한 종속성은 여전히 존재합니다. 컴파일러가 감지 할 수있는 방식이 아닙니다. JIT 컴파일러가 barfs를 사용하면 런타임 오류를 진단하기가 어려워집니다. –