인터페이스가 구현과 별도의 프로젝트에 있어야합니까?

Question

내 질문은 인터페이스 사용에 관한 것이 아니라 더 많은 프로젝트 조직의 특성입니다.

참고 : 다층 응용 프로그램에서 VisualStudio를 사용하고 있습니다.

인터페이스 파일이 구현과 별도의 프로젝트에 살아야합니까? 나의 초기 생각은 모든 서비스 인터페이스를 자체 프로젝트 (및 초기 구현을위한 프로젝트)로 분리하여 구현/콘크리트 프로젝트를 제거하고 필요한 경우 새로 교체 할 수 있도록 유용하다는 것입니다. .

예를 들으려면 : myapp.business.services 네임 스페이스에 사는 iBusinessService라는 비즈니스 계층 인터페이스가 있다고 가정합니다. 내 구현 foobusinessService는 동일한 네임 스페이스에 존재하지만 VisualStudio의 다른 프로젝트에 존재합니다. 나중에 구현을 재 작업 해야하는 경우 개발자는 fooservice.proj에 대한 참조를 제거하고 Barservice.proj에 대한 참조로 바꿀 수 있습니다.

이것은 콘크리트 구현 (쓸모 없거나 쓸모가 없거나 쓸모가 없을 수도 있음)을 얻지 않고 인터페이스 만있는 프로젝트를 참조 할 수있게함으로써 앱 솔루션을 정리하는 것처럼 보이지만 무언가를 놓치고 있습니까?

Answer 1

난 당신과 함께 있어요. 인터페이스를 별도의 프로젝트와 다른 네임 스페이스에 넣는 것을 선호합니다. 전형적인 예는 데이터 액세스 클래스입니다. 동일한 인터페이스를 구현하는 MSSQL 버전과 MySQL 버전을 코딩 할 수 있기를 원합니다. 따라서 인터페이스 정의는 별도의 어셈블리/프로젝트에있는 것을 선호합니다. 다음은 어셈블리와 네임 스페이스를 배치하는 방법의 예입니다.

• elder.dataaccess.core- 인터페이스와 공통 유틸리티가 포함되어 있습니다
• elder.dataaccess.mssql- 인터페이스의 특정 MSSQL 구현
• elder.dataaccess.mysql- 인터페이스의 특정 MySQL 구현

이를 통해 인터페이스 정의가 포함 된 프로젝트를 터치하지 않고 구현을 수정할 수 있습니다. 이것은 버전 제어 및 변경 추적에도 도움이됩니다. 이 고양이를 피부하는 다른 방법이있을 수 있으므로 다른 사람들의 대답을보고 싶어합니다.