서비스 계층 및 저장소 레이어가있는 ASP.NET MVC는 인터페이스를 어디에서 정의해야합니까?

Question

저장소 레이어와 서비스 계층이있는 .NET MVC 애플리케이션을위한 상당히 간단한 계층 아키텍처를 결정하는 과정에 있습니다. 나는 상당히 명확하고 간단한 예를 발견했습니다. www.asp.net, 여기에 몇 가지 질문과 답변이 있지만 소규모 응용 프로그램에 적합하지만 다른 프로젝트를 사용하여 아이디어를 얻을 수있는 무언가를 찾고 있습니다. 위의 예제에는 모델 네임 스페이스의 클래스로 리포지토리와 서비스가 있습니다. 그것은 내가 그것을 올바르게 설명 할 수 있도록 명확한 분리가 충분하지 않습니다.

인터페이스 Irepository를 구현하는 저장소에 대한 별도의 프로젝트가 있습니다. 서비스를위한 분리기 프로젝트가 있습니다. 서비스는 Iservice를 구현합니다. 이 예를 들어 컨트롤러가 서비스를 인스턴스화하는 것으로 충분합니다. 아직 IOC 컨테이너가 필요하지 않습니다. 이를 의존성 주입과 더 많은 층을 포함하도록 점진적으로 구축되는 시퀀스의 일부인 최상의 건축 관행을 이해하기위한 중간 단계로 생각하십시오.

문제는 어디에서 Ipository와 Iservice를 정의해야합니까? 서비스 및 저장소 프로젝트는 물론이를 참조해야합니다. 그렇다면 서비스 및 저장소 프로젝트 모두에서 참조 된 다른 프로젝트에서 정의되어야한다는 것이 분명해 보입니다. 그렇다면 좋은 이름 지정 컨벤션은 무엇입니까? xxxxcontracts와 같은 것이 있습니까?

마찬가지로, 프레젠테이션, 서비스 및 저장소 계층 사이에 전달 된 데이터 모델의 경우 모든 레이어에서 참조 된 XXXXXModels라는 별도의 프로젝트를 갖는 것이 허용됩니까? 어떤 경우에는 서비스 계층과 프리젠 테이션 계층 사이에 전달 된 모델과 다를 수 있지만 원리는 동일하다는 것을 이해합니다.

여기서 비슷한 질문에 대한 답변을 찾았지만 여기에서 설명한 것보다 더 복잡한 아키텍처를 포함하는 경향이 있습니다. 나는 데이터 계층을 참조하고 컨트롤러에 비즈니스 로직을 갖는 단계 또는 두 단계로 볼 수있는 두 계층의 정말 간단하고 깨끗한 그림을 달성하려고합니다. 나는 본격적인 모범 사례로 바로 가기위한 강력하고 유효한 주장이 있다는 것을 알고 있지만, 모든 사람이 한 번에 그 점프를하는 데 적합한 것은 아닙니다.

Answer 1

소개

이것은 내가 나 자신에게도 물어 본 것입니다. 내가 항상 가지고있는 한 가지 불타는 질문은 당신과 비슷합니다.

좋은 이름 지정 컨벤션은 무엇입니까?

어떻게 이름을 지정해야합니까? 폴더 나 프로젝트에 들어가야합니까?

주위를 검색 한 후에는 그 대답이 그게 의심됩니다 정말 중요하지 않습니다. 중요한 것은 솔루션이 현명한 아키텍처를 가지고 있고 다음과 같은 모범 사례를 따르려고한다는 것입니다. 단단한.

이 주제에 대한 내 ASP.NET MVC 영웅 제프리 팔레르모, 스티브 스미스 그리고 지미 보드.

양파 건축

Jeffrey Palermo는 오래된 아이디어의 조합을 논의하지만 함께 가져오고 시각적으로 자극적 인 이름을줍니다. 양파 건축 (권장 읽기). Jeffrey는 물건을 어디에 두어야하는지의 문제에 대한 좋은 접근법을 보여줍니다. 그는 응용 프로그램의 중앙 (또는 상단)에서 당신이 당신의 핵심. 이 레이어는 다음과 같은 인터페이스를 넣어야합니다. IRepository 그리고 IService.

거의 모든 인터페이스가 핵심으로 이동해야하며 다른 모든 (기타 프로젝트)는 모두 핵심을 참조 할 수 있습니다. 이런 식으로 모든 것은 구현 세부 사항을 모르고 응용 프로그램의 골격 구조를 알고 있습니다.

UI 계층 참조를 최대한 적게 사용하십시오 (이유 내). 내 응용 프로그램 중 하나에서 내 UI (MVC) 레이어는 코어 만 참조합니다. 필요한 모든 것이 주입됩니다 의존성 주입.

스티브 스미스 MVC 솔루션 모범 사례 : 솔루션 문제에 대한 솔루션

내 해결책

MVC 솔루션에서는 다음과 같은 일반적인 구조가 있습니다.

• myProject.core
• myproject.domain
• myProject.dependencyInjection
• MyProject.infrastructure
• myproject.web
• myProject.tests

그만큼 핵심 내 인터페이스를 포함합니다. 일반적으로 서비스, 모델, 도메인, 저장소 등과 같은 폴더로 나뉩니다.

그만큼 도메인 레이어 참조는 핵심 만 참조하고 내 구현을 포함합니다. 코어의 도메인 추상화에 대한 많은 콘크리트 클래스를 제공합니다. 많은 비즈니스 로직, 처리, 명령 처리, 관리자 클래스, 콘크리트 서비스 구현 등을 다룹니다. 나는 그것을 상당히 내부 층이라고 생각하므로 가능한 한 적게 참조합니다.

그만큼 의존성 레이어에는 선택한 DI 패키지/프레임 워크 및 구현 세부 사항이 포함되어 있습니다. 나는 그것을 외부 층이라고 생각합니다. UI 또는 인프라와 유사하므로 많이 참조해도 괜찮습니다. 이 레이어가 별도의 프로젝트가 될 필요는 없으며 많은 사람들 이이 작업을 수행하지 말라고 말할 것입니다. 괜찮아; 프로젝트의 복잡성에 맞는 일을하십시오. 나는 내 DI가 자신의 일이되는 것을 좋아합니다. 그것의 별개의 좋은 점은 DI 프레임 워크를 다른 프레임 워크로 대체 할 수 있다는 것입니다. 레이어는 DI 프로젝트를 참조합니다.

그만큼 하부 구조 계층에는 로깅, 이메일 및 데이터 액세스에 대한 정보가 포함되어 있습니다. 그것은 나의 것을 포함 할 것이다 ORM 선택의 여지가 있습니다. 그것은 비즈니스 로그의 물건이 아니며 UI가 아닙니다. 일을 끝내는 것은 내 솔루션의 철도입니다. 외부 층에 있지만 코어 만 참조합니다.

그만큼 편물 레이어는 MVC 프로젝트이며 핵심 만 참조합니다.

복잡성과 마지막 생각

여기서 비슷한 질문에 대한 답변을 찾았지만 여기에서 설명한 것보다 더 복잡한 아키텍처를 포함하는 경향이 있습니다.

좋은 지적입니다. 문제의 복잡성을 명심하는 것이 중요합니다. 그러나 좋은 솔루션 관행에 의해 저지되지 마십시오. 내 솔루션과 양파 건축은 반드시 매우 복잡한 것은 아니며 솔루션을 실제로 부풀릴 필요는 없습니다. 그들은 단지 물건을 별도로 유지합니다.

~ 안에 진화 프로젝트 구조, 지미 보가드 (Jimmy Bogard)는 과잉 복잡한 것들에 대해 이야기합니다. 내가 말한 것이 너무 복잡해 보이면 지미의 조언을 따르고 하나의 프로젝트 (UI 계층)에 넣으십시오. 괜찮습니다 - 그것이 당신에게 맞는 한.

내 솔루션을 아이디어로만 취해야합니다. 저의 접근 방식은 세이지의 조언을 최선을 다하려는 시도이지만, 나는 그렇게 성공했다고 확신합니다. 나는 여전히 개선 할 수있다.