재사용 가능한 라이브러리를 어떻게 구성합니까?

StackOverflow https://stackoverflow.com/questions/1249111

문제

불필요한 부풀어 오지 않고 비즈니스 프로젝트에서 쉽게 포팅 할 수 있도록 코드를 어떻게 구성합니까?

예를 들어 (.NET)에서 다음과 같은 네임 스페이스가 있다고 가정 해 봅시다.

namespace Computers
    - Hardware
         - Motherboard
         - GPU
namespace Monitors
    - Display
         - Mirrors
namespace Peripherals
    - USB
    - PS/2
  • 부모 네임 스페이스 당 프로젝트를 작성한 다음 다른 프로젝트에서 해당 DLL을 참조합니까?
  • 하나의 큰 클래스 라이브러리를 만들고 그 주위에 그 물건을 포트합니까 (도서관의 5% 만 필요하더라도)?
  • 아니면 하나의 파일을 만들고 필요한 코드를 해당 파일에 복사합니까? 그 파일을 "플러그 앤 플레이"아키텍처를 달성하는 데 필요한 모든 프로젝트에 그 파일을 만듭니다 (이것이 나쁘게 보이는 것처럼)?

편집하다:나는 .NET 답변을 구체적으로 찾고 있지는 않지만, 내가 사용하는 것은 구체적인 예입니다 (추상 예는이 경우에 질문을 이해하기가 더 어려워지기 때문에)

도움이 되었습니까?

해결책

부모 네임 스페이스 당 프로젝트를 작성한 다음 다른 프로젝트에서 해당 DLL을 참조합니까?

반드시 그런 것은 아닙니다. 내 라이브러리가 일반적으로 크지 않기 때문에 일반적으로 그런 식으로 끝납니다. 그러나 Microsoft는 확실히 그렇게하지 않을 것입니다. System.Weets System.Web 참조를 포함하지 않더라도 Web가 있습니다. 당신이 그렇게한다면 더 많은 수업을받습니다. System.Web 네임 스페이스가 여러 다른 DLL에 사용되었음을 나타냅니다.

하나의 큰 클래스 라이브러리를 만들고 그 주위에 그 물건을 포트합니까 (도서관의 5% 만 필요하더라도)?

예. 하드 드라이브 공간은 저렴하고 중복 코드를 유지하는 것보다 저렴합니다.

아니면 하나의 파일을 만들고 필요한 코드를 해당 파일에 복사합니까? 그 파일을 "플러그 앤 플레이"아키텍처를 달성하는 데 필요한 모든 프로젝트에 그 파일을 만듭니다 (이것이 나쁘게 보이는 것처럼)?

함수에 따라 다릅니다. 나는 보통 스 니펫에 이와 같은 것을 배치합니다. 예를 들어 내 웹 프로젝트에 나타나는 일반적인 기능은 다음과 같습니다.

void ShowErrorMessage(HtmlTableRow row, string message)
{
   row.Cells.Clear();
   row.Cells.Add(new HtmlTableCell());
   row.Cells[0].InnerHtml = message;
   row.Cells.Attributes.Add("class", "error");
   row.Visible = true;
}

라이브러리 기능을위한 좋은 후보처럼 보이지는 않습니다. 왜냐하면 내가 사용하고 싶었던 CSS 클래스와 때로는 셀의 콜스 판 값을 통과해야하기 때문입니다. 그러나 이와 같은 일종의 구현이 내 웹 프로젝트의 몇 곳에 앉아있는 것을 볼 수 있습니다.

다른 팁

나는 DNA에서 신호를 받고 하나의 프로젝트에서 도서관의 1% 만 사용하더라도 프로젝트에서 프로젝트에서 하나의 거대한 클래스 라이브러리의 전부 또는 일부를 복사합니다. 필요에 따라 방법과 수업을 자유롭게 다시 작성합니다.

이 접근법은 기존의 프로그래밍 지혜와는 다소 반대이지만, 나는 그것을 두드리지 않을 것입니다. 지난 35 억 년 동안 생물을 위해 매우 성공적으로 일했습니다. 인생에서와 마찬가지로, 대안 (프로젝트 전체에서 편집 된 어셈블리를 공유하여 인터페이스와 구현을 강화)은 변화를 방해하고 사실상 멸종을 보장합니다.

각 구성 요소를 이산 모듈로 유지하고 사용합니다. Maven 내 종속성을 관리하려면 (Java를위한 것이 아니라, 이것을 참조하십시오. 의문, byldan .NET에 해당합니다).

이렇게하면 프로젝트에 포함하지 않고도 코드를 재사용 할 수 있습니다. 위의 예에서는 3 개의 아티팩트가있을 수 있습니다. 각 네임 스페이스 당 하나는 함께 유지해야 할 이유가 없다면 (이로 인해 느슨한 커플 링을 시행하는 데 도움이됩니다).

최근에 프로젝트 수를 줄이려면 결국 생성 된 실제 어셈블리의 수가 줄어든 경우에만 프로젝트 수를 줄이려는 것을 발견했습니다. 개발 중에 처리하기가 더 쉽습니다. 이것은 아마도 모듈 식적이고 서로 독립적 인 프로젝트를 만드는 것이 어렵 기 때문일 수 있습니다.

일반적인 규칙은 다음과 같습니다. 프로젝트가 실제로 다른 모든 것과 독립적으로 개발 될 수 있고 다른 의존성없이 다른 프로젝트에 연결할 수 있다면 자체 프로젝트로 만듭니다. 작동하기 위해 참조 해야하는 다른 프로젝트가 항상 있다는 것을 알게된다면 (예 : 모니터 프로젝트에서는 GPU 클래스에 컴퓨터 네임 스페이스를 포함하지 않으면 아무것도 작동하지 않을 것입니다), 그런 다음 하나의 프로젝트에 합류했습니다.

그 외에도 규칙이 너무 어렵고 빠르다고 생각하지 않습니다. 실제로 어셈블리의 내용에 대한 많은 것에 달려 있습니다. 임의의 규칙을 만드는 것은 어렵습니다 ...

내 두 센트,별로 가치가 없습니다 ...

나는 단일 DLL로 시작하고 그것이 점점 커지고 상당히 독립적 인 구성 요소를 포함하기 시작하면 별도의 DLL으로 고려할 수 있습니다. 저에게는 주로 미학의 문제입니다. 저는 사물을 독립적이고 직교 및 잘 조직 유지하는 것을 좋아합니다. 요즘 메모리의 양, 디스크 공간을 고려할 때 큰 DLL에 아무런 문제가 없습니다.

여러 프로젝트에서 공유되는 물건의 경우 일반적으로 하나의 큰 DLL 접근 방식을 사용합니다. 이 사람을 사용하는 많은 프로젝트가 있다면 강력한 이름을 지정하고 GAC에 던지는 것이 좋습니다. 점점 더 많은 프로젝트를 추가 할 때 결국 당신이 달릴 수있는 것은 공유 구성 요소를 깨뜨리는 욕구입니다. 강력한 이름 지정/GAC를 사용하지 않으면 변경할 때 모든 앱을 업데이트해야하며 필연적으로 하나를 잊어 버리면 제작중인 무언가가 폭발 할 것입니다.

강한 이름으로, 릴리스 버전을 소스 컨트롤의 중앙 집중식 폴더에 보관하고 항상 참조하십시오. 그런 다음 배포 당시 GAC에 던져 넣습니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top