개발자의 의견/관행에 궁금한 점이 있습니다. 클래스 인터페이스가 이상적으로 .NET 클래스 라이브러리에 있어야합니다. MyCompany.AccountPackage.Interfaces와 같이 솔루션 내에서 전용 라이브러리에 포함되어야합니까?클래스 인터페이스는 어디에서 .NET 클래스 라이브러리에 배치해야합니까?
예를 들어 자신의 네임 스페이스가 있어야합니다. MyCompany.AccountPackage.MasterAccounts.Interfaces?
다른 의견/의견을 바랍니다.
.Net 라이브러리 (또는 더 나은 솔루션)를 구조화하는 방법을 설명하는 데 유용한 가이드가 있습니까? 일반적으로 표준 라이브러리에서 어떤 클래스/인터페이스가 노출되어야하는지 일반적으로 보여줍니다.
감사합니다. d.
짧은 대답 :
인터페이스는 구현 된 위치에 가깝습니다.
적어도 BCL 중 일부는 IEnumerable<T>이 System.Collections.Generic 네임 스페이스에 있습니다.
약간 더 이상 대답은 :
이 인터페이스의 목적이 무엇인지에 따라 달라집니다.
제 3자를 위해 플러그인 인터페이스 (제공 업체 모델 또는 MEF)를 제공합니까?
그렇다면 별도의 어셈블리가 이해 될 수 있으므로 제 3 자에 의해 가져와야하는 모든 어셈블리가이 어셈블리입니다.
테스트 및 IoC 용도로 내부적입니까?
나는 구현에 가깝게 유지하는 것이 조직적으로 의미 있고 인터페이스와 코드를 동기화하는 데 도움이된다고 주장한다.
후 다음을 참조하십시오 : 이러한 인터페이스가 여러 어셈블리에 의해
을 사용됩니다
Proper .NET DLL structure for app
그리고, 일반적으로 다음과 같은 질문에 대답하려고?
줄일 수 있습니까? 어셈블리 및 참조의?
dll 카운트를 줄이기 위해 비 관련 인터페이스를 단일 어셈블리에 포함하려고합니까?
확장 성 및 유지 보수에 대해 생각하십니까?
대답은 인터페이스가 무엇이며 어떻게 라이브러리의 아키텍처에 맞는지에 따라 다릅니다.당신이 개체 모델의 형태를 만드는 경우
개체 모델 제 생각에는
, 당신은 어셈블리 내에서 하나 개의 프로젝트에서 개체 모델을 나타내는 인터페이스를 놓아야합니다. 이렇게하면 실제 구현에 대해 걱정할 필요없이 인터페이스에 대한 참조를 다시 분산하고 코딩 할 수 있습니다. 또한 객체 모델의 초기 구현을 제공하면서 다른 사람이 (새 플랫폼이나 관련 소프트웨어를 지원하기 위해) 다시 구현할 수 있도록 허용합니다.
일반 사용
당신이 많은 장소에서 다시 사용하려고하는 .NET의 System.Collections.Generic 네임 스페이스에있는 것과 유사한 인터페이스를 만드는 목적으로하는 경우; 그런 다음 여러 프로젝트가 인터페이스에 액세스하고 구현할 수 있도록 충분히 낮게 배치 할 것을 제안합니다. 그러나 이것이 동일한 프로젝트 내에서 직접 인터페이스를 구현할 수 없다는 것을 의미하지는 않습니다. 이 경우, 그것은 모두 당신의 의도를 그 어셈블리 안에서 결정합니다.
다른 사용
또 다른 용도는 일부 데이터베이스 인터랙를 정의하는 인터페이스가 일부 데이터베이스 상호 작용 시스템을 수 있지만, 당신이 그것의 두 개 이상의 구현을 가질 수있다. 예를 들어 Microsoft Access 데이터베이스와 상호 작용하는 데이터베이스와 SQL 데이터베이스와 상호 작용하는 데이터베이스가있을 수 있습니다. 이 경우 동일한 어셈블리에서 인터페이스 및 구현을 제공하는 것이 가능할 수 있습니다.
이 모든 것은 상황과 의도 된 용도에 따라 달라집니다. 그것이 무엇인지를 결정하는 가장 좋은 방법은 어셈블리의 프로토 타입 버전을 만들고이를 사용하는 방법을 확인하는 것입니다.
대부분의 상황에서와 같이 : 상황에 따라 다릅니다.
그러나 모든 경우의 99 %에서 인터페이스를 자체 어셈블리에 배치하고 논리적 단위로 그룹화하여 엄격한 인터페이스 종속성을 방지했습니다. 전날에는 첫 번째 구현이 있던 곳에 넣었습니다. 이것은 나중에 분리 될 수없는 단단히 결합 된 엉망으로 성장했습니다.
느슨한 커플 링을 연습하고 노력한다면 별도의 인터페이스로 인터페이스를 이동하는 것이 좋습니다. I만을 선호 가 포함
"인터페이스 어셈블리 '으로 만 기준으로) 지금까지 변경하지 않습니다 또는 상속 할 것들
이것은 하나의 어셈블리에서만 사용되는 내부 인터페이스 (인터페이스의 1 %)에는 적용되지 않습니다. 인터페이스 자체가 하나 같이 동일한 어셈블리에 포함 할 수
유일한 구현이 :
입니다. 또한 구현을 직접 사용하지 않거나 인터페이스가이 특수 구현인지 테스트합니다.
왜? 이렇게하면 어셈블리가 안정된 어셈블리에만 의존하고 단단히 결합되지 않습니다. 의존성 주입을 사용하려는 경우에도이 방법을 사용하는 것이 좋습니다.
당신은 인터페이스의 하위 네임 스페이스의 구현을 넣어해야합니다. 따라서, 귀하의 예를 데리러, 내가 좋을 것 :
MyCompany.AccountPackage.MasterAccountsMyCompany.AccountPackage.MasterAccountsMyCompany.AccountPackage.MasterAccounts.SQLMasterAccounts 또는 단지 MyCompany.AccountPackage.MasterAccounts.Implementation.왜?
구현 측면에서 보면 using MyCompany.AccountPackage.MasterAccounts.Interfaces을 사용할 필요없이 모든 인터페이스와 확장 프로그램을 사용할 수 있습니다.
클라이언트 측면에서 이것은 구현 어 그리이스 (어쨌든 다른 구현 어 셈 블리를 포함해서는 안 됨)에서 인텔리 센스의 너무 많은 옵션으로부터 보호되지만 주 어셈블리의 구현에 쉽게 액세스 할 수 있다는 것을 의미합니다. 사용할 구체적인 구현을 선택합니다.
인터페이스를 완료 한 모든 과정과 자습서에서 항상 –
클래스 바로 위에 배치됩니다. 자신의 네임 스페이스 또는 라이브러리를 제공하지 않을 것입니다. 슈퍼 영리한 사람들 중 한 명이 * .NET Framework Design Guidelines *에서 논쟁 한 것처럼 (어느 것이고, 내 책이 편리하지 않다는 것을 기억하지 못한다.) 인터페이스를 제공해서는 안된다. 그 인터페이스. 따라서 인터페이스를 구현과 동일한 네임 스페이스에 배치하십시오. –
즉, 나는 실제로 당신이 쓰는 인터페이스의 수를 최소화하려고 노력할 것이고, 가능하다면 추상적 인 클래스를 선호한다. 이렇게하면 인터페이스의 거의 모든 장점을 얻을 수있을뿐만 아니라 많은 메소드에 대한 기본 구현을 제공 할 수 있습니다. 그러나 이것은 정말로 주관적입니다. 나는 그것이 SO에 적합한 주제인지 확신 할 수 없다. –