StartUp.cs에서 DbContext를 참조하면 .NET 핵심 응용 프로그램에서 아키텍처가 엉망입니다.

-1

올바르게 흐르게되지만로드 블록으로 계속 실행되는 프로젝트 구조를 제안하려고합니다. 특히 EF에 대한 DbContext가 어디에 있어야 하는지를 알 수없는 곳입니다. 내 API가 내 데이터 계층을 참조하는 것을 원하지 않습니다. 내가 생각할 수있는 유일한 방법은 EntityFramework를 도메인 계층에 설치하고 거기에 DbContext를 저장하는 것입니다.StartUp.cs에서 DbContext를 참조하면 .NET 핵심 응용 프로그램에서 아키텍처가 엉망입니다.

TestProj.Data 클래스 라이브러리 (.NET 코어)
엔티티 프레임 워크가 설치되어 있습니다. UnitOfWork 클래스, 데이터베이스 호출을하는 모든 리포지토리가있는 Repositories 폴더가 들어 있습니다. EF 마이그레이션도 포함됩니다. 해당 비즈니스 엔터티에 대한 TestProj.Domain을 참조하십시오.

TestProj.Domain 클래스 라이브러리 (.NET 코어) 모든 사업체, IUnitOfWork 인터페이스와 TestProj.Data 즉 ICustomerRepository의 저장소에 대한 모든 인터페이스와
모델 폴더에 있습니다.

TestProj.Api 웹 API 프로젝트 (.NET 코어)
나는이 만 TestProj.Domain를 참조해야한다 생각하지만, 나는 시작 프로그램으로 설정하기 위해 또한 모든 서비스를 TestProj.Data를 참조해야 .cs, 즉

services.AddDbContext<TestProjDbContext>(options =>   options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection"))); 
     services.AddTransient<IUnitOfWork, UnitOfWork>(); 
     services.AddTransient<ICustomerRepository, CustomerRepository>();

여기서 내가 혼란스러워지기 시작합니다.

내 질문 :
가이 도메인 및 데이터 프로젝트 모두를 참조하는 API 프로젝트를위한 괜찮은? StartUp.cs에서 종속성 주입을 설정하기 위해 필요한 것처럼 보입니다.

Domain 프로젝트의 모든 인터페이스를 설치하고 있습니까?

TestProjDbContext는 EF를 위해 어떤 프로젝트를 사용해야합니까? 필자의 초기 생각은 데이터 프로젝트 였는가?

DTO/Pocos와 같은 항목은 어디에 있습니까? API 프로젝트 또는 도메인 프로젝트에서? API는 AutoMapper가 설치되어 있고 TestProj.Domain을 참조하므로 원래 비즈니스 엔티티를 API의 DTO에 매핑 할 수 있다고 가정합니다.

마지막으로 비즈니스 로직은 어디에 있습니까? 데이터 영역과 API 사이의 규칙 나는 적절한 장소가 TestProj.Domain이라고 가정하고있다. API가 IUnitOfWork를 API 컨트롤러에 주입하는 대신 도메인의 비즈니스 로직에 대해서만 호출하면 TestProj.Domain.Services.CustomerService를 삽입 할 수 있습니다. 이게 말이 돼? 이에

출처

2017-04-18 Blake Rivell

물론 이것은 너무 독설적 인 것으로 간주 될 수 있습니다. 그러나 여기에 당신이 고려해야 할 것이 있습니다. 무언가가 DbContext를 사용하고 있다면, EF 라이브러리를 참조하는 것을 막을 방법이 없습니다. 당신이하고 싶은 것은 API가'List '과 같은 일반적인 구문을 사용하거나 그렇지 않다는 것입니다. 다음 아키텍처를 고려할 수도 있습니다. http://jeffreypalermo.com/blog/the-onion-architecture-part-1/ 또는 http://codingcanvas.com/hexagonal-architecture/ –

또한 Unit of Work는 다음과 같이 중복됩니다. DbContext는 이미 작업 단위이기 때문에 DbContext를 사용하고 있습니다. 그런 추상화를 만드는 거의 모든 사람들이 (IQueryables와 같은) 구현 세부 사항을 누설하여 실제로 데이터 기술을 바꾸는 것을 어렵게 만듭니다. –

@ErikFunkenbusch 꼭 그렇지는 않습니다. 예, EF는 기본적으로 작업 단위이지만, 다른 ORM으로 교환하려는 경우 우려 사항을 분리하는 것은 어떻습니까? 또한 응용 프로그램 전체에서 중복 코드/쿼리 논리의 양을 줄이려는 시도는 어떨까요? UoW 및 Repository 패턴 w/EF를 구현해야하는 이유는 많습니다. –

내 의견 :

그것은 도메인 및 데이터 프로젝트 모두를 참조하는 API 프로젝트를위한 괜찮은?

괜찮습니다.

Domain 프로젝트의 모든 인터페이스를 사용하고 있습니까?

YES

TestProjDbContext는 EF 어떤 프로젝트를 앉아서해야합니까? 필자의 초기 생각은 데이터 프로젝트 였는가?

나는 보통 DTO들 같은 항목을

이/포항 강판은 이동 도메인 프로젝트에 BlahBlahContext 클래스를 배치? API 프로젝트 또는 도메인 프로젝트에서?

Dto라는 다른 프로젝트를 위해 만들었습니다. 필요할 때이를 참조하십시오.

U API는 AutoMapper가 설치되어 있고 TestProj.Domain을 참조하므로 원본 비즈니스 엔티티를 API의 DTO에 매핑 할 수 있다고 가정합니다. 물론

마지막으로

, 어디 비즈니스 로직은 이동 하는가? 데이터 영역과 API 사이의 규칙

나는 솔루션이 다른 프로젝트에 사용 ->라는 서비스를이 도움이

희망을.

출처

2017-04-18 04:22:54 paulpeters

우수한 응답! 따라서 Domain 프로젝트에 DbContext를 두어 Api 및 Data 프로젝트 모두에서 참조 할 수 있도록해야합니다.DbContext를 전달해야하기 때문에 StartUp.cs에서 ef sqlserver 서비스를 구성 할 때 막혔습니다. Api에서 내 데이터 프로젝트를 참조하고 싶지 않았습니다. 비록 당신이 괜찮다고 말하고 있지만, 나는 Api가 서비스 프로젝트에 대해서만 알고있는 것을 선호합니다. 이것도 괜찮습니까? –

> Api에서 내 데이터 프로젝트를 참조하고 싶지 않았습니다. -> Api에서 Data 프로젝트 수업을 어떻게 계획합니까? Automapper에 필요하기 때문에이를 참조해야합니다. "저는 Api가 서비스 프로젝트에 대해서만 알고 있다고 생각합니다." (서비스를 훨씬 더 잘 사용하여 비즈니스 로직을 Api에 배치하고 싶지 않다는 의미입니다.) – paulpeters

서비스를 통해서만 Api의 데이터 프로젝트 클래스로 작업 할 계획입니다 (서비스 만 데이터 프로젝트와 대화합니다). 함수). 예를 들어 GetCustomerById 및 GetCustomers와 같은 비즈니스 로직이없는 기본 클래스조차도 CustomerService에서 호출 될 것입니다.이 방법을 사용하면 내 컨트롤러에 ICustomerService 만 주입합니다. Api/Mvc 컨트롤러에 서비스와 리포지토리를 모두 주입하는 것이 정상입니까? 나는 또한 서비스가 리포지토리에 전화를 걸 것이라고 가정하고 있습니다. 나는 이것이 나의 혼란의 대부분이있는 곳이라고 생각한다. –

StartUp.cs에서 DbContext를 참조하면 .NET 핵심 응용 프로그램에서 아키텍처가 엉망입니다.

답변

관련 문제