.NET 프로젝트/네임 스페이스 조직 질문

Question

우리는 많은 인터페이스와 기본 기본 구현을 정의하는 프레임 워크를 가지고 있습니다. CompanyFramework라고 부르 자. 현재 별도의 CompanyFramework.Web.Mvc 프로젝트에 저장되어있는 ASP.NET MVC 확장이 있습니다. 그 이유는 핵심 프레임 워크를 사용하지만 MVC와 아무 관련이없는 응용 프로그램이 ASP.NET MVC 라이브러리를 참조 할 필요가 없기 때문입니다. 여분의 어셈블리에는 3-4 개의 클래스 파일 만 포함되어 있으므로이 설정이 마음에 들지 않지만 기본 프레임 워크 어셈블리에 불필요한 종속성을 피하는 가장 깨끗한 방법이었습니다.

이제 우리는 ASP.NET MVC, 즉 사용자 지정 컨트롤러 팩터 리 및 모델 바인더 유형 항목에 사용되는 일부 StructureMap 관련 확장을 제공합니다. 너 어디서 그런 걸 넣을거야? CompanyFramework.Web.Mvc 프로젝트에 그냥 던져 넣을 수 있습니다. 그러나 사용중인 ASP.NET MVC 프로젝트는 StructureMap 어셈블리에 대한 참조를 사용합니다. 또한 별도의 CompanyFramework.StructureMap 프로젝트를 만들 수도 있지만, ASP.NET MVC에 의존하지 않는 StructureMap의 확장을 개발하는 경우에는 해당 클래스를 사용하는 클래스에 대해 MVC 어셈블리를 참조하는 데 여전히 빠져 있습니다.

별도의 CompanyFramework.Web.Mvc.StructureMap 프로젝트를 만들어야합니까? 이 접근법은 전반적으로 가장 깨끗하게 보입니다.하지만 전반적인 프로젝트 구조가 어지럽게 흩어지는 가벼운 위성 어셈블리를 소개하기 시작했습니다.

Answer 1

이와 같은 질문에 대해서는 향후 수정에 대한 결정의 장기적인 영향을 고려하는 것이 도움이된다는 것을 알고 있습니다. 결국,이 라이브러리 중 일부는 폐기되고 대체 될 것이고 다른 라이브러리는 계속 살 것이다. 예를 들어, MVC를 대체 할 일부 기술이 적용될 것입니다.

이러한 것들을 분리하면 미래의 개발자와 유지 보수 담당자의 삶이 훨씬 쉬워 질 것이라고 저는 믿습니다. 종속성은 더 명확하며 항상 좋은 것입니다. 마이그레이션 결정은 더 큰 자신감과 명확성으로 이루어질 수 있습니다.

계속 확장되는 머드 라이브러리의 빅 볼은 앞으로 다른 많은 이유로 인해 모든 프로젝트에 관심을 갖고 싶어하지 않을 것입니다. "가벼운 조립체"는 나에게 훌륭한 설계 목표처럼 들립니다.

Answer 2

더 나쁜, 나쁜 의존성 또는 소수의 추가 프로젝트가 있습니까? 약간 복잡하게 얽힌 IDE는 잘 정의 된 구조에 대해 지불 할 작은 가격입니다.

Answer 3

MVC 프로젝트에 StructureMap을 배치하는 것이 좋습니다. 나는 이것이 논리적으로 가장 합리적이라고 생각하며, 어떤 경우에는 사용되지 않는 참조가 문제가되지 않을 것이라고 생각한다.

당신의 현재 설정 (CompanyFramework 어셈블리 + MVC 어셈블리)은 꽤 합리적이라고 생각합니다. 공통 어셈블리, 웹 어셈블리 (또는 특히 MVC 또는 웹 폼을 대상으로 함), 데이터베이스 어셈블리 등과 같은 동일한 패턴을 따르는 것으로 나타났습니다. 이렇게 높은 수준으로 분리하면 시작하기 좋은 곳.