.dll 구조 설계를위한 리소스

Question

방금 ​​디자인 미팅에서 나왔고, 우리가 구축하고있는 프로젝트의 일부 .dll을 구조화하는 방법에 대한 아이디어를 어디서 가지고 있는지에 대한 질문을 받았습니다. 솔직하게 말해서 나는이 "아이디어"가 어디에서 나온 것인지 전혀 모른다. 나에게 자연스러운 지식처럼 보였다. 그러나 문서화 된 분석을 통해 이러한 의견을 뒷받침 할 수 있다면 유용 할 것입니다.

누구나 어셈블리/모듈/소스를 구조화하기 위해 다른 메커니즘을 설명 할 수있는 리소스를 알고 있습니까?

는 UPDATE :

는 잘 생각은 특별한 것이 없었다. 우리는 일부 하드웨어의 추상화 계층에 대해 논의 중이므로 이러한 서비스를 사용하는 "응용 프로그램"은 플랫폼 독립적 인 (일종의) 플랫폼이 될 수 있습니다. 이전에는 우리가 가지고있는 인터페이스를 선언하는 인터페이스 .dll과 지금까지 가지고 있던 하나의 플랫폼에 대해 구현 한 .dll 구현이있었습니다. 이제 우리는 두 개의 플랫폼을 가지고 있지만 그것들은 매우 유사합니다. 인터페이스가 .dll이 오염되는 것을 막기 위해 구현이 서로를 참조하는 끔찍한 시나리오를 피하기 위해 우리는 일반적인 추상 구현이 살아갈 수있는 인터페이스와 specificplatform.dll 사이에 다른 .dll을 만들 것을 제안했습니다.

Answer 1

는 기회가 있다면, 로버트 C. 마틴 책을 살펴 있습니다

Agile Principles, Patterns, and Practices in C#을

(이 특별히 닷넷을 대상으로 새로운 버전) 구성 요소에 전념 한 장있다 귀하의 질문에 대한 답을 (아마도) 디자인하십시오.

• 어셈블리 단위 또는을 다시 요약 :

  , 그 책을 읽은 후, 나는 항상 이러한 기준에 의해 분리 구성 요소를 권장 함께 사용할 수있는 클래스가있는 경우, 그들이가는 같은 어셈블리에서.

• 어셈블리가 변경 단위입니다. : 같은 이유로 변경하지 않아도되는 클래스가있는 경우, 동일한 어셈블리에 있어서는 안됩니다.

• 어셈블리는 배포 단위입니다. : 물리적으로 같은 위치에 배포해야하는 클래스가있는 경우 동일한 어셈블리에 있어야합니다.

는 물론 이건 그냥 휴리스틱하지 요리법입니다. 결과적으로 응용 프로그램의 아키텍처 목표 (특히 배포 및 진화/수정에 대한 아키텍처 목표)를 기반으로 필요한 세 가지 설계 휴리스틱의 양을 결정해야합니다.