2016-11-10 2 views
1

Google 소프트웨어의 API 호출을 포함하는 DLL의 세 가지 버전을 만들어야합니다. 나는 지금까지 상속을 사용하여 그것을하는 다음과 같은 방법을 알아 냈다. 누군가 내가 올바른 방법으로 상속을 사용하고 있는지 확인하십시오 (또는 적절한/더 나은 방법을 제안 했습니까?) 저는 C# 프로젝트 프로그래밍을 배우는 것에 익숙합니다. 그런 다음소프트웨어의 다른 버전에 맞는 C# DLL을 빌드하는 최선의 방법은 무엇입니까?

namespace APIcalls 
{ 
    public partial class API_Calls 
    { 
    public void Common_function1() 
    { 
    } 

    public void Common_function2() 
    { 
    } 
    } 
} 

은 내가 그들 각각에 다음과 같은 세 가지 .cs 클래스 파일이 (Edition_A을 다음과 같이

지금까지 내가 (모든 DLL 버전에 대한 공통) API_calls의 주요 클래스가

각 어셈블리 빌드에서
namespace dll_edition 
{ 
public class Edition_A 
{ 
    public Edition_A() 
    { 
     // Code here for checking if current DLL is authorized 
     // Otherwise throw an exception 
    } 
} 
} 

namespace APIcalls 
{ 
    public partial class API_Calls : Edition_A 
    { 
    public void Additional_Edition_A_function1() 
    { 
    } 

    public void Additional_Edition_A_function2() 
    { 
    } 
    } 
} 

내가 Edition_A 파일을 포함, 또는 : Edition_B 및 Edition_C)는 DLL의 각 버전에 대한 다른 요인 다음과 같이 추가 호출은 부분 클래스 API_Calls에 포함되어 있습니다 Edition_B 파일 또는 Edition_C 파일을 만든 다음 세 개의 DLL을 제공하는 세 가지 어셈블리를 모두 빌드합니다.

내 질문 : 적절한 방법입니까? 내가 그 일을 어떻게했는지에 대해 부정적인 점이 있습니까? 아니면 이것을하는 더 좋은 방법이 있습니까? 내 궁극적 인 목표는 몇 가지 공통된 API 호출이 포함 된 세 가지 DLL 버전과 각 DLL 유형에 대한 다양한 API 호출을 사용하는 것입니다.

입력 해 주셔서 감사합니다. 내가 이해, 당신은 다른 다른 클래스에서 사용되는 공통 기본 클래스에 일반적인 기능의 설정에서

-DD

+2

왜 모든 DLL이 하나의 dll에 있고, 실행중인 에디션을 기반으로 특정 API 호출에만 액세스 할 수있는 것은 아닙니다. 하나의 코드베이스 만 유지하게됩니다. – Dispersia

+0

DLL의 크기를 줄이려고했는데 (그렇지 않은 경우 거의 12MB였습니다.) 400 개가 넘는 API 호출이한데 모여서 더 좋은 방법이 있는지 확실하지 않았습니다. 더 나은 방법이 있습니까? 동일한 솔루션 내에 모든 파일이 있습니다. 단지 하나의 코드 기반 만 유지하는 것이 아닙니까? – EmbeddedDude

+2

깨끗한 코드와 관련하여 FCoI라는 규칙이 있습니다. 상속보다 컴포지션을 선호합니다. 아마도 당신은이 시나리오에서 그것을 이해하고 사용하려고 시도 할 수 있습니다. 상속은 강력한 커플 링을 생성하므로 나중에이를 변경하기가 어렵습니다. 대신 구성을 사용하면 다양한 방법으로 내용을 구성 할 수 있습니다. 느슨한 커플 링을 사용하여 물건을 교환 할 수 있습니다. 나중에 라이선스를 변경하기로 결정한 경우 –

답변

0

.

자신의 장단점을 수행하는 여러 가지 방법이 있습니다 : - 제한된 기능은 사용자와 DLL의 크기를 끝으로 이동하는 당신이하고 각 유형에 대한 별도의 라이브러리를 만들기

1) small.this는 dll이 plus에서 작업하고 bin 디렉토리에 dll을 덤프하는 모델을 재생하는 경우에 더 적합합니다. 새로운 기능이 추가되었습니다.

또한 변경 사항을 중심으로 변경하여 변경 내용을 알 수 있습니다. 그러나 dll을 최종 클라이언트에 배포하고 다른 dll에서 메서드가 필요한 경우에는 변경 내용을 다시 게시해야합니다.

2) 1 dll에서 모두 수행하면 원치 않는 기능이 클라이언트에 노출되므로 배포 패키지가 무거울 수 있습니다. 그러나 모든 기능을 즉시 사용할 수 있습니다.

요약하면 주로 비즈니스 및 배포 모델에 따라 달라집니다.

+0

DLL 접근 방식을 사용할 수 없기 때문에 고객은 매우 제한된 리소스를 사용하는 임베디드 프로세서 보드에서 사용하므로 플래시 저장 용량이 제한되어 있습니다. 우리의 dll은 필요한 모든 호출 (거의 4 우리는 나중에 새로운 보드 (하드웨어)를 필요로하기 때문에 DLL을 개정 할 필요가 없습니다. – EmbeddedDude

+0

그런 다음 이미 필요한 작업을하고 있습니다 –

0

개인적으로 하나의 DLL에서 모든 것을 수행하고 런타임에 어떤 버전이 실행되는지 확인하기 위해 Factory Pattern을 사용하는 것이 더 큰 팬이지만, 필자의 요구 사항에 따라 3이되어야한다면 여기에 내가 추천하는 것이있다.

4 개의 DLL을 생성하십시오.

첫 번째 프로젝트에는 버전 인터페이스 만 포함됩니다 (예 : DLL의 구조, 작동 방식에 대한 내용 없음). 이 인터페이스는 다른 버전의 DLL에 대한 클래스에 연결할 수 있습니다. 이 구조체를 사용하면 DLL의 다른 버전에 대한 종속성 삽입을 사용할 수 있도록 호출 코드가 설정됩니다.

다른 3 개의 DLL은 빌드해야하는 다른 DLL 버전입니다.

+0

제공된 링크에서 바로 이해한다면, 좋아 보인다. 팩토리 패턴은 모든 것을 하나의 DLL에 내장해야한다는 것을 요구한다. 제한된 자원으로 임베디드 보드에 저장 될 때 DLL 크기를 줄이는 것이 나의 임무 중 하나이다. :-( – EmbeddedDude

+0

그렇다면 의존성 주입은 갈 경로와 같이 보입니다. 내 대답의 두 번째 부분이지만, 내가 쓴 것을 다시 읽은 후에는 실제로 튀어 나오지 않았습니다. – jbeverid

관련 문제