모범 사례 : LINQ의 3 계층 아키텍처

Question

LINQ에서 SQL을 사용하는 개인 프로젝트 (C# / ASP.NET)를 연구하고 있습니다. 이 솔루션은 (지금까지) WebForm 프로젝트, 네임 스페이스 프로젝트 (비즈니스 로직) 및 테스트 프로젝트를 갖습니다. 나는 지금까지 매우 초기 단계에 있습니다 (분명히 디자인 단계).

여기에 3 계층 아키텍처에 대한 패러다임이 있습니까? 이 경우 달이 완전히 쓸모없는 것 같습니다. 비즈니스 로직에서 직접 LINQ 쿼리를 수행해야한다고 생각합니다.

또한 하나의 거주자 데이터 컨텍스트를 유지하고 주변을 통과하면 하나의 열린 연결 만 있으면됩니다. 이것은 세분화 된 대신 한 번에 변경 사항을 한 번에 저지르는 이점이 추가됩니다. 그것에 대한 생각이 있습니까?

나는 찾았다 이 스레드, 그러나 불완전한 그림을 그리는 것 같습니다. 주제에 대한 심층적 인 기사가 있습니까?

Answer 1

linq-to-sql을 dal로 생각할 수 있으므로 "비즈니스 로직에서 직접"사용하는 것이 반드시 나쁜 것은 아닙니다.

http://dotnetlog.com/archive/2008/03/18/best-practice-and-effective-way-of-using-datacontext-n-linq.aspx 인기있는 L2S 접근법이 나열되어 있습니다.

프로젝트에서 우리는 데이터 컨텍스트를 전달하고 싶지 않아 위의 링크에서 #3과 유사한 패턴을 사용했습니다 (주변 데이터 콘텍스트, 아래 참조). 몇 가지 문제가 있었지만 합리적으로 잘 작동했습니다. 적어도 우리 웹 프로젝트의 경우.

Ambient DataContext (현재 사용 중)

Ambient DataContext의 아이디어는 Datacontext에 대한 첫 번째 호출이있는 즉시 특정 스레드 또는 httpcontext (asp.net)에 대해 컨텍스트가 생성된다는 것입니다. 그런 다음 수동으로 배치되지 않는 한 해당 스레드 또는 요청에 동일한 컨텍스트가 사용됩니다. 이는 요청/스레드 데이터 저장소에 컨텍스트를 저장하여 수행됩니다. 이 패턴에 대한 접근 방식은 정적 데이터 콘텍스트와 유사하지만 각 스레드 및 요청에 대해 분리가 제공됩니다. 그러나 이것은 ASP.NET에서 실제로 잘 작동하지만 정적 컨텍스트의 일부 문제에 의해 다시 시행됩니다.

이 패턴의 문제 :

* The context is available for manipulation at any level. And quickly becomes very hard to maintain unit of work
* Portability across thread is very hard
* Unit of work pattern is not transparent enough

Answer 2

도메인 구동 디자인에서 약간 읽을 수 있습니다.

DDD (Domain Driven Design)의 연습을 통해 다루고 자하는 문제 도메인을 표현하는 리치 '도메인 모델'이 있습니다. 이 도메인 모델은 비즈니스 엔티티를 모델링하는 클래스 (및 스트러크)로 구성됩니다. 도메인 모델은 또한 리포지토리를 고려합니다.
저장소는 도메인 모델 (및 응용 프로그램)에서 사용하는 일종의 추상화입니다. 저장소는 데이터 스토어의 추상화입니다. 저장소를 통해 엔티티를 검색 할 수 있으며 저장소를 사용하여 지속 엔티티를 사용할 수 있습니다.

귀하의 경우, 저장소는 LINQ에서 SQL을 내부적으로 사용하여 데이터베이스와 대화 할 수 있습니다. 그러나 리포지토리는 연결 및 트랜잭션 (시작/커밋/롤백)을 관리 (개방/닫음) 할 책임이 없어야합니다. 왜요 ? -> 저장소에 사용되는 컨텍스트에 대한 지식이나 개념이 없기 때문입니다. 새로운 연결을 열고 트랜잭션을 시작 / 커밋 해야하는 것은 응용 프로그램 또는 서비스 계층 (도메인 모델 및 저장소를 사용하는 레이어)입니다. (또는 귀하의 경우 새 DataContext를 엽니 다). 그런 다음 데이터 콘텍스트를 저장소로 전달할 수 있습니다.

(Eric Evans는 때때로 DDD에 관한 훌륭한 책을 가지고 있습니다.

Answer 3

당신은 당신의 용어에주의해야합니다. LINQ라고 말할 때 LINQ-to-SQL을 의미하고 3 계층이라고 말하면 일반적으로 3 개의 별도 시스템으로 배포 시나리오에 대해 이야기하고 있습니다. 그것이 당신이 의미하는지 확실하지 않습니다.

LINQ-to-SQL과 같은 ORM 도구를 사용할 때는 3 층 아키텍처는 여전히 좋은 아이디어입니다. DAL은 쿼리 로직을 저장할 수있는 장소가됩니다. 쿼리는 비즈니스 논리 문제가 아니라 지속성 문제이기 때문에 비즈니스 계층에서 쿼리를 제거하는 것이 좋습니다.

데이터 컨텍스트를 관리하기위한 일반적인 기술은 요청 당 단일 데이터 컨텍스트를 갖는 것입니다.

주제에 관한 다른 기사와 관련하여 모든 ORM 도구에 대한 아키텍처 지침 -Linq-to-SQL은 다르지 않습니다. nhibernate의 아키텍처에 관한 기사를 찾으십시오.

Answer 4

이 경우 LINQ에서 SQL 라이브러리가 DAL이며, 비즈니스 계층 (예 : dal.getObjectById (ID))에서 기존 API 호출을하는 대신 DAL에 대한 훨씬 더 표현적인 요청의 유연성이 있습니다.

다른 요구가있는 경우, 예를 들어 MSSQL이 아닌 데이터 백업에 연결되는 자신의 LINQ 제공 업체와 같은 경우 자신의 DAL을 구현합니다.

또한 DataContext와 관련하여 "하나의 거주 데이터 콘텍스트"가있는 싱글 톤 패턴을 사용하는 것이 좋습니다. DataContext 객체는 응용 프로그램의 의미가 무엇이든 단일 논리적 트랜잭션을 나타냅니다. (파라피스에서 http://weblogs.asp.net/despos/archive/2008/03/19/more-on-datacontext-in-hopely-a-realistic-world.aspx)