아직까지는 내 프로그램이 다른 프로그램과 구별되는 경향이 있으므로 .NET에서 DLL을 만들 필요가 없습니다. 긴). 그러나 나는 많은 프로그램 (또는 좀 더 일반적인 방법으로 만들 수있는 유사한 방법)에 복사본이있는 경향이있는 정기적으로 사용되는 방법의 라이브러리를 모으기 시작했습니다.자신의 DLL을 언제 만들어야합니까?
나는 그것을 이해해야하므로 dll은 프로그램들간에 공통적 인 방법을 공유하기 위해 만들어 져야한다.
그래서 dll에 내 메서드를 넣을 수 있습니다. 사용자 지정 대화 상자 및 일반 폼과 같은 것은 어떻습니까? 현재 거의 모든 프로그램에서 사용되는 사용자 정의 오류 양식과 인쇄 미리보기 대화 상자가 있습니다. dll에 넣는 것이 좋은 습관입니까?
이 경우 "우수 사례"는 실제로 코드 중복을 줄이는 방법에 의존합니다. 이 대화 상자가 많은 프로그램에서 사용되어 많은 코드를 사용한다면 예, 공유 공간으로 옮기는 것이 좋습니다.
하지만 모든 것을 던지려하지 마십시오. 당신이 그것을 무시해야한다는 것을 알게 될 것이고, 그 시점에서 아마도 당신은 이전보다 더 많은 코드를 작성했을 것입니다. 일을 단순하게 유지하십시오. 일반 사항으로 유지하십시오. 유용하게 유지하십시오.
시작하기 전에 종속성 트리를 작성한다는 점에 유의하십시오. 라이브러리 기회를 업데이트하면이를 사용하는 앱을 유지 관리해야합니다.하지만 타사 라이브러리를 사용하는 것과 다르지 않습니다.
새 dll을 만들려면 솔루션에 새 프로젝트 (라이브러리)를 추가하고 주 프로그램에 프로젝트 참조로 추가하기 만하면됩니다.
이 프로젝트에 원하는 것을 넣을 수 있습니다. 모든 대화 상자, 사용자 컨트롤 등은 단지 클래스이므로 다른 클래스처럼 쉽게 공유 할 수 있습니다. 나는 가능한 한 많이 나누는 것이 좋은 습관이라고 생각합니다.
왜 안 되니?
여기에 빌드하는 것은 실제로는 .Net 프레임 워크와 거의 같은 작은 프레임 워크입니다. 폼, 메소드, 비즈니스 로직, 예외, 공통 데이터 액세스 등 애플리케이션에서 공통적으로 생각하는 모든 것이 어셈블리에 포함될 수 있습니다.
프레임 워크가 커지면 해당 공용 DLL을 분할 할 수 있습니다. 예를 들어 DLL에 일반적인 양식이 있고 일괄 응용 프로그램을 개발하는 경우 WinForms 특정 클래스가 포함 된 DLL을 참조 할 필요가 없습니다.
또는 이러한 방법에 대한 소스 파일을 일반적인 위치에 넣고 프로젝트/솔루션에 포함 할 때 링크로 추가 할 수 있습니다.