.NET 응용 프로그램간에 코드를 공유하는 가장 효과적인 방법은 무엇입니까? 기본 기능을 공유하는

우리의 작업에는 많은 기본 기능을 공유하는 여러 가지 .net 응용 프로그램이 있습니다. 우리는 깔끔한 n- 계층 아키텍처를 사용하여 이러한 응용 프로그램을 구축했지만 동일한 기능을 여러 번 다시 구현했다는 사실을 깨달았습니다. 분명히 이것은 DRY를 위반하므로 우리는 그것을 수정하고 싶습니다. 우리는 이미 일반적인 글루 코드 (IoC 연결, 로깅, 설정)를 위해 Nuget을 사용하고 있지만 모든 애플리케이션간에 데이터 및 비즈니스 계층을 공유하고 싶습니다. 아이디어는 UI가 실제로 필요한 비즈니스 계층의 일부만 처리한다는 것입니다.

이것은 처음에는 간단한 문제처럼 보이지만 진행중인 개발은 약간의 함정을 제공 할 수 있으며 진행 방법을 잘 모릅니다. 우리가 하나의 비즈니스 계층을 모든 것을 지배한다고 가정 해 봅시다. 간결하게하기 위해 “창립”이라고 부릅니다. 우리는 Foundation을 사용하기 위해 응용 프로그램을 이식하고 모든 것이 뛰어납니다. Foundation은 너겟을 통해 가벼운 UI 레이어에 배포되며 우리는 좋아 보입니다. 그러나 애플리케이션에 기능을 추가하기 시작하고 문제가 발생합니다.

프로젝트 A에서 작업 중이며 Foundation을 변경해야하는 새로운 기능을 추가한다고 가정하겠습니다. 우리는 재단 (Foundation-A)을 변경하고 불안정한 패키지로 너겟 피드에 밀어 넣습니다. 프로젝트 A는 최신 너겟 패키지를 얻었으며 모두 좋습니다. 한편, 다른 개발자가 프로젝트 B를 작업 중입니다. 소스 제어에서 최신 Foundation을 가져 오지만 안정적인 지점에서 가져와 프로젝트 A에 변경 사항이 없습니다. 그는 변경을하고 Foundation-B를 만들었습니다. 그리고 모두 좋다. 그러나 실제로 코드를 공유 할 수있는 Foundation-A 및 Foundation-B 구현 기능을 발견하여 결합합니다. 한편 Foundation-C는 자체 변경 사항이 반영되어 있습니다. 결국 Foundation-B는 생산 준비가 완료되었으므로이를 추진합니다. 그런 다음 프로덕션 A, B를 업데이트해야합니다.

이것은 작동하는 것처럼 보이지만 다른 데이터베이스 스키마로 작업하고 Foundation 리포지토리의 다양한 브랜치와 프로젝트 A, B 및 C 리포지토리간에 모든 항목을 동기화하는 것이 걱정됩니다. 아마도 많은 수동 작업이 필요할 것 같으며 오류가 발생할 가능성이 있습니다. 가능한 한 자동화를 원합니다.

우리가 사용하는 스택은 다음과 같습니다 : C #, TFS with Continuous Integration, Nuget. 우리의 응용 프로그램은 모두 다양한 유형의 ASP.NET 응용 프로그램입니다. 우리는 일을 더 쉽게 할 수 있도록 다른 SCM을 기꺼이 살펴볼 것입니다.

Nuget을 다른 소스 코드 브랜치로 유지하는 방법을 찾고 있습니다. 우리는 잘못된 Nuget 패키지를 참조하기 때문에 개발 코드를 실수로 프로덕션으로 푸시하고 싶지 않습니다.



답변

우리는 재단 (Foundation-A)을 변경하고 불안정한 패키지로 너겟 피드에 밀어 넣습니다.

여기 문제가 시작되는 곳이 있습니다. 그렇게하지 마십시오.

Foundation v1.0의 모든 변경 사항은 본질적으로 Foundation의 모든 소비자에게 가치가 있어야합니다. 그렇지 않으면 Foundation에 속하지 않습니다. 따라서, nuget 패키지를 만들 때, 공식적이고 안정적인 Foundation 버전 (예 : v1.1)으로하거나 전혀하지 마십시오.

프로젝트 B는 평상시와 같이 재단 개선 사항을 구축해야하지만 (좋은 소스 관리 방식으로) 안정적인 재단 (v1.2)을 마비시키기 전에 트렁크 변경 (v1.1)을 병합해야합니다.

Foundation 개선 사항을 사용할 수있는 다른 프로젝트는 적절한 경우 Nuget 참조를 업그레이드하거나 필요한 경우 이전 버전을 사용할 수 있습니다.

@Giedrius에 동의합니다 . 이것은 Foundation의 분기 / 병합이 제대로 처리되면 패키지 관리 문제가 무의미하다는 점에서 소스 제어 / 분기 문제에 더 가깝습니다.


답변

중복 된 코드를보다 추상적 인 방식으로 적용 할 수있는 함수로 리팩터링하여 자체 라이브러리 또는 프레임 워크에 넣습니다. 그것들을 느슨하게 결합하고 아키텍처에 구애받지 않게 만들면 아무런 문제가 없을 것입니다. 영감이 필요한 경우 .NET 프레임 워크가 인터페이스, 제네릭 및 같은 소프트웨어 패턴을 사용하여 개념을 추상화하는 방법을 연구하십시오 Dispose().

또한 모든 중복 코드가 실제로 복제되는 것은 아닙니다. 그중 일부는 아키텍처를 유지하는 데 필요한 접착제 코드 또는 코드이므로 너무 건조하는 것에 집착하지 마십시오.


답변

코드 재사용

지난 몇 년 동안 코드 재사용에 대한 몇 가지 접근 방식이 선호되었습니다. 각 접근 방식에는 그 위치가 있으며 더 중요한 문제 는 있지만 .NET에서 코드를 재사용하는 가능한 방법은 다음과 같습니다.

  1. 공통 도서관. 둘 이상의 장소에서 필요한 코드는 공통 라이브러리에 저장되며, 코드베이스의 다른 모든 부분에는이 코드에 대한 단일 참조가 있습니다. 원칙 단점은 많은 관련없는 기능을 포함하는이 라이브러리에 따라 대부분의 프로젝트로 끝나는 것입니다. 이것은 품질 보증 측면에서 나쁜 생각입니다.

  2. 공통 소스 코드. 둘 이상의 위치에 필요한 코드는 한 번 작성되고 공통 디렉토리 구조의 소스 파일에 배치됩니다. 이 코드가 필요한 모든 프로젝트는이 파일을 소스 파일 중 하나로 포함시킵니다. 이것은 코드 재사용을 제공하고 한 번 쓰기의 장점은 많이 사용합니다. 하나. 단점은이 코드의 다른 버전으로 컴파일 된 프로젝트의 다른 부분을 가질 수 있다는 것입니다. 이는 품질 보증으로 감지하고 식별하기가 매우 까다로운 미묘한 결함을 유발할 수 있습니다.

  3. 서비스. 공통 코드는 다른 측면에서 액세스 할 수있는 서비스로 구현됩니다. 이는 배치에 단일 서비스가 있으며 종속성을 피할 수 있다는 이점이 있습니다. 그러나 대기 시간과 실패가 발생합니다. 이러한 종류의 접근 방식은 고 가용성 및 내결함성이 이미 이해되고 관리되는 대규모 분산 제품에서 잘 작동합니다.

NuGET 관리

여기에 훨씬 더 흥미로운 문제가 있습니다. 여러 구성 관리 여기서 조언은 다양한 코드 버전이 아닌 구성 파일을 사용하여 다양한 고객 기반을 관리하는 것입니다. 관리 할 구성 데이터 계층은 3 개 이상입니다. 고객이 볼 수없는 기본 (내부) 제품 구성. 고객이 변경할 수있는 기본 구성 옵션 및 고객이 변경 한 구성 옵션의 마지막 계층. 이러한 여러 계층을 분리하면 고객 구성을 손상시키지 않고 업그레이드를 롤아웃 할 수 있습니다.


답변

나는 문제가 너겟 / 소스 제어 / 브랜치가 아니라 접착 코드에 빠지는 것으로 생각합니다.

Robert는 전체 그림을보기 위해 이러한 일반적인 유틸리티가 각 프로젝트에 어떤 종속성을 가져 오는지 생각해 보는 것이 좋습니다.

http://ayende.com/blog/3986/let-us-burn-all-those-pesky-util-common-libraries
http://blog.jordanterrell.com/post/CommonUtility-Libraries-Dead.aspx

지옥을 피하는 가장 좋은 방법은 접착제 코드를 오픈 소스로 만드는 것입니다. 이러한 방식으로 비즈니스 로직이 공개되지 않기 때문에 구체적인 프로젝트 의존성이 접착제 코드에 빠지지 않을 것이므로 회사 외부에서도 누구나 재사용 할 수있을 정도로 추상적 일 수 있습니다. 코드는 충분할 것입니다-커뮤니티의 의견도 얻을 수 있습니다.


답변

해결책은 간단합니다. 별도의 프로젝트를 만들고 별도의 것으로 관리합니다. 자체 요구 사항, 테스트, 컨벤션, 문서, 계획, 사람 등입니다. 이렇게하면 품질이 유지되고 주요 변경 사항이 발생할 수 있습니다. 문제를 만들기 전에 먼저 평가합니다.

또는 더 나은 : 조직 내에서 “오픈 소스”로 만드십시오. 따라서 누구나 코드를 변경할 수 있지만 일부 선택된 사람 만 완전한 커밋 권한을 갖습니다. 그리고 그 사람들은 품질과 올바른 기능을 보장 할 책임이 있습니다.


답변