다른 프로젝트간에 클래스 또는 인터페이스 공유


17

나는 SO 또는 여기에서 몇 가지 대답을 찾고 있었지만 결과가 없으면 이것이 내가 당신에게 묻는 이유입니다.

앱의 서버 부분과 클라이언트 부분과 같은 두 가지 다른 프로젝트가 있다고 가정 해 봅시다. 내 친구가 두 번째를 만드는 동안 내 자신의 부분을 개발하고 있습니다. 그러나 우리 모두 는 호환성을 보장하기 위해 Useror AccountInfo또는 ChangableAccount... 와 같은 일반적인 인터페이스를 사용해야합니다 . 예를 들어 클라이언트가 사용자 데이터를 서버로 보내는 경우 서버는 동일한 클래스에서 작동해야합니다. 인터페이스와 동일합니다. 또한 공통 인터페이스가 변경되면 두 프로젝트 모두 코드를 새로운 상황에 맞게 조정해야합니다.

내가 지금 볼 수있는 유일한 해결책은 모든 공통 사항이 정의 된 하나의 추가 프로젝트를 만드는 것입니다. 나와 내 친구 인이 프로젝트를 기본 프로젝트 (클라이언트 또는 서버)에 대한 종속성으로 추가해야합니다. 일부 버전 제어 시스템에서 공유 프로젝트를 관리 할 수 ​​있으므로 항상 최신 상태를 유지합니다.

다른 해결책을 제안 하시겠습니까? 전문 앱에서 이러한 문제가 어떻게 해결됩니까?


1
공유 여부를 버전 관리해야합니다. 클라이언트 및 서버 프로젝트에 버전 제어를 사용 하고 있지 않다고 말하는가 ? 그렇다면 즉시 해결하십시오.
Sebastian Redl

답변:


15

모든 공통 사항이 정의 된 하나의 추가 프로젝트를 만듭니다.

이것은 재사용 가능한 부품을 공유하는 첫 번째 단계이며 쉬운 부분입니다. 가장 어려운 부분은 공유 라이브러리를 사용하는 두 개의 프로젝트가 독립적 인 릴리스주기를 가질 지 여부를 결정하고, 프로젝트 B가 사용하는 동안 "프로젝트 A"가 공유 라이브러리의 버전 1.0을 사용할 수 있는지 여부를 결정하는 것입니다. 동시에 버전 2.0 .

후자를 가능하게하려면 라이브러리 (및 @RoryHunter가 제안한 라이브러리 파일 이름의 일부로 버전 번호)에 대한 엄격한 버전 관리 체계 및 릴리스 관리가 필요합니다. 이 상황에서 lib의 하위 호환성도주의해야합니다. 라이브러리는 별도의 제품으로 관리해야하며, 제품에 다른 단위 버전을 추가하여 프로덕션 환경의 다른 버전이 좋은 아이디어인지 확인하고 Maven과 같은 도구도 의미가 있습니다.

그러나 이러한 상황을 방지 하려면 개발, 빌드 및 릴리스 프로세스를 결합하여 "프로젝트 A", "프로젝트 B"및 lib를 공통 프로젝트로 관리해야합니다. 이를 통해 첫 번째 시나리오보다 공유 라이브러리의 공통 인터페이스를 훨씬 더 자주 변경할 수 있습니다. 그리고 라이브러리 파일 이름에 Maven 또는 버전 번호와 같은 것이 필요하지 않습니다. 그러나 A와 B는 더 이상 독립적으로 개발 될 수 없다는 단점이 있습니다.


13

귀하의 솔루션이 옳습니다. 공유 코드를 자체 JAR 파일을 빌드하는 다른 프로젝트에 넣고 두 프로젝트 모두에서 사용하십시오. JAR 파일을 빌드 할 때 데비안 스타일과 같은 이름으로 버전을 포함 할 수 있습니다.

libmyproject-shared-1.0.jar

버전 관리 문제를 방지하지는 않지만 도움이됩니다. 나는 Maven을 사용한 적이 없지만이 상황에서 도움이 될 수 있음을 이해합니다.


2

모든 공통 사항이 정의 된 하나의 추가 프로젝트를 만듭니다.

이것이 바로 .Net이 기대하는 방식입니다.

이러한 객체를 세 번째 어셈블리로 추상화하고 두 프로젝트에서이를 참조하십시오. 더 깔끔한 인터페이스로 제안하는 것이 좋지만 ...

직렬화에주의하십시오 :

  • 두 프로그램간에 개체를 직접 직렬화 / 직렬화 해제 할 수있는 유일한 방법은 (클래스 2.0을 사용 하는 것이 분명한 일임 ) 클라이언트와 서버 컴퓨터 모두에서 전역 어셈블리 캐시에 "공유"어셈블리를 설치하는 것입니다. 어셈블리가 각 프로젝트에 대해 "로컬"인 경우 프레임 워크는이를 개별 유형으로보고 하나를 다른 것으로 직렬화하지 않았다.
  • 그리고 인터페이스로 타입 지정된 객체를 직렬화 해제하는 것은 약간의 "도전"입니다. 원래의 비 인터페이스 유형은 직렬화 "파이프"를 통해 "만들지"않은 것처럼 보였으므로 수신기는 들어오는 스트림에서 "구축"할 구체적인 유형을 알지 못했습니다.

1

다른 사람들이 제안했듯이, 당신의 사고 과정은 정확합니다. 전문적으로 Maven 또는 Gradle 과 같은 것을 사용 하여 이러한 종속성을 효율적으로 관리합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.