LINQ와 데이터 액세스 계층

나는 항상 비즈니스 로직과 UI 코드에 대해 완전히 별도의 '계층'으로 데이터 액세스 코드를 처리하도록 가르쳤다. 이것은 항상 나에게 아주 좋은 아키텍처였으며 내가 본 '규칙'이나 모범 사례는 여전히 이러한 스타일의 코딩, 특히 단일 책임 원칙에 적합 합니다.

대부분의 가정 프로젝트에는 필자가 만든 자체 ORM을 사용하며 항상 오픈 소스를 만들려고했습니다. 그러나 그 이후로 LINQ를 사용할 수있게되었으며 이는 ORM의 작동 방식과 매우 유사했습니다 (그러나 더 좋습니다).

이전에는 LINQ로 수행 할 수없는 내 자체 ORM으로 이전에 수행 할 수있는 작업이 없습니다 (REST 통합 비트 제외). 내 질문은; LINQ가 새로운 데이터 액세스 계층입니까? 더 이상이 레이어가 필요합니까? 내 BLL이 LINQ와 직접 대화해야합니까? 아니면이 나쁜 습관이 여전히 있습니까?

편집하다:

원래 질문은 LINQ to Entities에 관한 것이지만 LINQ to SQL에 대한 흥미로운 답변이 많이 있습니다. 두 사람에 대한 사람들의 생각은 무엇입니까? LINQ to SQL보다 DAL을 실제로 대체 할 수는 없지만 Entity Framework는 수집 할 수 있습니까?

BLL에 LINQ 쿼리를 넣을 수는 있지만 코드 복제로 이어질 수 있습니다. LINQ 쿼리의 래퍼가 될 리포지토리를 계속 만듭니다. 이렇게하면 데이터베이스 코드가 BLL 코드 와 분리 되며 데이터 액세스 코드를 수정 (예 : Dapper 또는 사전 컴파일 된 쿼리로 이동)하기로 결정할 때 유용합니다.

리포지토리를 쉽게 조롱 할 수 있으므로 단위 테스트 에도 도움이됩니다 .

여전히 DAL을 가질 수 있지만 이전에 사용한 것 대신 LINQ to SQL을 사용할 수 있습니다. 어쨌든 내가 그렇게하는 방법입니다. BLL이 LINQ to SQL을 직접 사용하여 데이터에 액세스하게하지 마십시오.

Linq는 데이터 액세스에 관한 것이 아닙니다 IEnumerable.

처음에 데이터베이스에 대해 생각하지 않고 응용 프로그램을 설계하려고 했습니까? 즉, 응용 프로그램을 구현하고 어떤 종류의 저장소를 사용하십시오. 그런 다음 모든 기술을 사용하여 해당 저장소를 구현하십시오. 그렇게하면 원하는 데이터 액세스 계층을 플러그인 할 수있는 완전히 분리 된 솔루션이 있습니다.

해당 데이터 액세스 계층에서 자체 ORM을 사용하거나 Linq를 사용하여 SQL을 사용할 수 있습니다. 데이터 액세스 계층이 정의한 리포지토리를 구현하는 한 중요하지 않습니다.

"비즈니스 로직 계층"이 트랜잭션 및 쿼리 성능을 처리하기를 원하지 않는 한 여전히 DAL이 필요합니다.

LINQ는 쿼리 선언을 디자인 타임 (일명 컴파일러 검사) 프로세스로 만듭니다.

LinqToSql 및 LinqToEntities와 같은 LINQ 쿼리 공급자는 여전히 선언 된 쿼리를 SQL 텍스트로 런타임 변환합니다. 그런 다음 DBMS는 여전히 런타임 쿼리 해석, 런타임 쿼리 계획 생성 등을 수행합니다.

이것들은 DAL의 작은 부분 일뿐입니다.