네임스페이스/솔루션 구조

https://stackoverflow.com/questions/12243

08-06-2019
|

문제

이렇게 일반화된 질문을 해서 죄송합니다만, 제게는 어려울 수 있는 질문입니다.우리 팀은 수년에 걸쳐 발전해 온 임의의 일회성 코드베이스를 모두 하나로 모으는 대규모 프로젝트에 곧 착수할 예정입니다.이 프로젝트가 회사 전체의 논리적 엔터티("고객", "직원") 표준화, 작은 작업, 작은 작업을 제어하는 큰 작업 및 유틸리티 서비스를 다룰 것이라는 점을 감안할 때 저는 이 프로젝트를 구성하는 최선의 방법을 찾기 위해 고군분투하고 있습니다. 네임스페이스와 코드 구조.

계속해서 설명할 만큼 구체적인 내용을 충분히 제공하지 못한 것 같지만, 도메인을 논리적으로 분할하는 방법에 대한 리소스나 조언이 있나요??도움이 될 경우, 이 기능의 대부분은 웹 서비스를 통해 공개될 것이며, 우리는 마이크로소프트 최신 장치와 장치를 모두 갖춘 쇼핑을 즐겨보세요.

참조를 더 쉽게 만들기 위해 하위 프로젝트가 포함된 하나의 대규모 솔루션에 대해 토론하고 있지만 그렇게 하면 너무 다루기 힘들까요?
레거시 애플리케이션 기능을 마무리해야 할까요, 아니면 완전히 불가지론적으로 네임스페이스에 남겨 두어야 할까요? OurCRMProduct.Customer 클래스 대 일반 Customer 예를 들어 수업)?
각 서비스/프로젝트에 고유한 것이 있어야 합니까? BAL 그리고 DAL, 아니면 모든 것이 참조하는 완전히 별도의 어셈블리여야 합니까?

저는 이렇게 광범위한 프로젝트를 조직한 경험이 없고 일회성일 뿐이므로 얻을 수 있는 지침을 찾고 있습니다.

해결책

고양이의 가죽을 벗기는 방법은 백만 가지가 있습니다.그러나 가장 단순한 것이 항상 최고입니다.당신에게 가장 간단한 방법은 무엇입니까?귀하의 요구 사항에 따라 다릅니다.하지만 제가 따르는 몇 가지 일반적인 경험 법칙이 있습니다.

첫째, 전체 프로젝트 수를 최대한 줄입니다.하루에 20번 컴파일하면 추가 시간이 늘어납니다.

앱이 확장성을 고려하여 설계된 경우 디자인 라인과 디자인 라인에 따라 어셈블리를 분할하는 것을 고려하십시오.구현.인터페이스와 기본 클래스를 공용 어셈블리에 배치합니다.회사에서 이러한 클래스를 구현하기 위한 어셈블리를 만듭니다.

대규모 애플리케이션의 경우 UI 로직과 비즈니스 로직을 별도로 유지하세요.

솔루션을 단순화하세요.너무 복잡해 보인다면 아마도 그럴 것입니다.결합하고 줄입니다.

다른 팁

비슷한 작업을 시작한 내 조언은 이름 공간에 대해 고민하지 말라는 것입니다.

몇 가지 중요한 느슨한 지침을 가지고 개발을 시작하세요. 어떻게 시작하든 프로젝트는 유기적이며 ~ 할 것이다 결국 시간이 지남에 따라 네임스페이스와 클래스를 재구성하게 됩니다.

프로젝트에 대해 너무 많이 이야기하는 데 시간을 낭비하지 마십시오.그냥 해.

나는 최근 직장에서 똑같은 일을 경험했습니다.구조화하고 구성해야 하는 임시 코드가 많습니다.

양이 너무 많아서 처음에는 정말 어렵습니다.제가 드릴 수 있는 최선의 조언은 다음과 같습니다. 거기에 시간을 투자해 금요일 오후에 바람이 불면 몇 주 동안 저는 앱/코드 덩어리를 선택하고, 거기에 무엇이 있는지 조사하고, 우리가 일반으로 만들 수 있는 것이 무엇인지 생각하고, 그것을 복사하고, 제가 생각하는 곳에 새 라이브러리에 넣곤 했습니다. 그것은해야한다.애플리케이션 내의 모든 코드를 마이그레이션한 후에는 공통 프레임워크에서 작동하도록 애플리케이션을 리팩터링하는 작업을 진행했습니다.이로 인해 수정이 필요한 문제가 발생하는 경우도 있었지만 철저하게 수행하는 한 그다지 큰 문제는 아닙니다.

하나씩, 그게 유일한 방법입니다.

구조 측면에서 MS 네임스페이스를 모방하려고 노력했습니다. 대부분의 경우 꽤 논리적이기 때문입니다(예: 회사.데이터 , 회사.웹 , 회사.웹.UI 등등.

주요 이점 중 하나는 아마도 중복된 코드가 제거된다는 점일 것입니다.예, 앱에는 약간의 리팩토링이 필요했지만 코드 기반은 훨씬 더 간결하고 여러 면에서 "더 똑똑"합니다.

내가 알아차린 또 다른 점은 내가 종종 문제를 해결하는 데 어려움을 겪는다는 것입니다. 어디 그것이 무엇에 속하는지 확신할 수 없었기 때문에 (네임스페이스 측면에서) 물건을 넣으려고 했습니다.이제 이 정말 걱정이 되어서, 냄새가 너무 지독하다고 생각했어요.재구성 이후 모든 것이 이제 훨씬 더 멋지게 공간에 들어갑니다.그리고 (지금은 매우 적은 양의) 애플리케이션 특정 코드를 사용하여 회사.응용 프로그램.응용 프로그램 이름 이 네임스페이스 내에서 너무 많은 것을 원하지 않기 때문에 비즈니스 개체에 대해 훨씬 더 많이 생각하는 데 도움이 되므로 보다 유연한 디자인을 생각해 낼 수 있습니다.

글이 길어져서 죄송합니다..그것은 일종의 방황입니다!

.NET에서 어셈블리 이름을 Company.Project.XXXX.YYYY로 지정합니다. 여기서 XXXX는 프로젝트이고 YYYYY는 하위 프로젝트입니다. 예를 들면 다음과 같습니다.

LCP.AdmCom.Common
LCP.AdmCom.BusinessObjects
LCP.AdmCom.Common.Dal

우리는 이것을 북콜에서 가져왔습니다 프레임워크 디자인 지침 작성자: Krzysztof Cwalina(지은이), Brad Abrams(지은이)

대규모 프로젝트의 경우 제가 선호하는 접근 방식은 비즈니스 개체에 대해 하나의 도메인 네임스페이스를 갖고 비즈니스 개체의 저장 및 검색이 필요한 계층에서 DTO(데이터 전송 개체)를 사용하는 것입니다.DTO는 비즈니스 논리를 포함하지 않는 간단한 개체입니다.

다음은 DTO를 설명하는 링크입니다.

http://martinfowler.com/eaaCatalog/dataTransferObject.html

프로젝트가 많은 대규모 솔루션은 컴파일 속도가 상당히 느릴 수 있지만 함께 관리하기는 더 쉽습니다.

테스트 중인 것과 동일한 솔루션에 단위 테스트 어셈블리를 사용하는 경우가 많습니다. 어셈블리를 함께 변경하는 경향이 있기 때문입니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow