전 항상 Linq2SQL 쿼리를 장소의 거의 모든 클래스에 삽입했습니다.Linq2SQL 쿼리를 장소 또는 전용 DAL 클래스에 두시겠습니까?
필자는 Linq2SQL 쿼리를 어디에 두어야하는지에 대한 전략을 알고 싶습니다.
별도의 데이터 계층 클래스에 넣거나 장소 전체에서 어디에 사용합니까?
Linq2SQL 쿼리에 대한 내 전략을 변경하고 별도의 DataLayer 클래스에 저장해야한다고 생각합니다. 나는 TDD을 효율적으로 할 수 있고 의존성 주입과 솔리드 원리를 준수 할 수 있다면 필수적이라고 생각합니다.
LINQ2QL 쿼리로 LINQ 쿼리를 생각하면 약간의 요점을 놓치고 있습니다. .
LINQ 쿼리가 있습니다. 비즈니스 계층은 데이터 계층 (데이터 인터페이스)에서 LINQ 쿼리를 수행하여 데이터 계층에 액세스합니다. LINQ2SQL은 LINQ 쿼리가 SQL Server에 액세스하도록 허용하는 구성 요소입니다.
큰 과다 단순화가 있지만 모든 LINQ를 비즈니스 계층에서 숨기고 그 이유가 실제로 존재하지 않는다면 일반적인 점이 있습니다.
LINQ2SQL에서 DB 스키마를 원하는 정도로 추상화 할 수없는 경우 대신 엔티티 프레임 워크를 사용해보십시오.
데이터 레이어 내에서 쿼리를 결합하여 멋진 작업을 수행 할 수 있고 LINQ 쿼리를 작성하는 것이 종종 SQL을 작성하는 것보다 쉽고 빠르기 때문에 이익이되지 않는다고 동의합니다. 또한 IMO는 LINQ2SQL이나 EF도 쿼리를 작성하는 사람이 수행중인 작업을 알지 못할 정도로 데이터베이스를 추상화하지 않습니다. 쿼리 작성자가 Linq2Object 대신 EF를 사용하고 있다는 사실을 알지 못해도 EF에도 너무 많은 잡아 당김과 지원되지 않는 것들이 있습니다. – tster
모든 Linq2SQL 쿼리를 별도의 클래스에 넣으면 액세스하는 비즈니스 객체를 테스트 할 때 "모의/스텁"으로 쉽게 교체 할 수 있습니다.
아니면 내가 잘못입니까?
@Leffe - Data Context 주위에 DataContextWrapper를 작성하여 LINQ2SQL을 조롱하거나 스터 빙하는 문제를 해결합니다. 그런 다음 필요에 따라 컨텍스트 래퍼를 작성할 수있는 팩토리를 삽입합니다. 이를 통해 적절한 mock/fake 팩토리를 사용하여 유닛 테스팅을위한 데이터 컨텍스트를 모의하거나 가짜로 만들 수 있습니다. – tvanfosson
자세한 내용은이 블로그 게시물을 참조하십시오. 이것은 나의 출발점이었다. http://andrewtokeley.net/archive/2008/07/06/mocking-linq-to-sql-datacontext.aspx – tvanfosson
저는 모든 LinqToSQL 호출을 하나의 DAL로 완전히 래핑했습니다. 내 웹 사이트 및 비즈니스 계층에는 내가 사용중인 지속성 프레임 워크에 대한 지식이 없습니다. 이런 식으로 LinqToSql이 정말로 죽지 않거나 완전히 새로운 프레임 워크를 사용하기로 결정했다면 DB 호출을 한 모든 장소를 검색 할 필요가 없습니다.
또한 재사용에 도움이됩니다. 동일한 데이터베이스를 사용하는 다른 프로젝트에서 동일한 비즈니스 또는 DAL을 사용할 수 있습니다.
그러면 비즈니스 계층에 Linq2SQL "Entities"에 매핑되는 자체 POCO가 있습니까? – Nate
필자는 일반적으로 레이어간에 사용되는 엔티티의 인터페이스 유형을 포함하는 공통 프로젝트를 가지고 있습니다. Linq2Sql 엔터티가 부분 클래스를 사용하여 이러한 공통 인터페이스를 구현하도록 만든 다음 내 쿼리 메서드에서 다른 클래스로 반환 할 수 있습니다. 특정 레이어가 공통 인터페이스 중 하나를 구현하는 새로운 것을 필요로하는 경우에는 자체 엔티티를 만들고 관리하고 인터페이스를 구현합니다. 따라서 엔티티를 사용하는 레이어 간의 모든 통신은 인터페이스 유형입니다. – Vyrotek
일반적인 POCO를 사용하고 DAL에서 매핑하는 것보다이 방법을 사용하면 어떤 이점이 있습니까? 나는 이것이 지금 내가하는 일이고, 또한 당신의 방법으로 가능한 drawbank를 볼 수 있다고 생각하고있다. 당신은 당신의 DAL로부터 쓰레기를 모으는 것을 막고 LINQ2SQL의 DataContext는 수명이 짧을 것으로 생각된다. 내 포인트가 유효한지 확실하지 않아서 내가 생각하는 것을 듣고 싶습니다. –
LINQ는 언어 구조입니다. 필요한 것은 DAL이 엔티티를 IEnumerable 또는 IQueryable로 노출하고 LINQ를 사용할 수있는 것입니다. DAL은 LINQ2SQL 또는 LINQ2Entities 또는 사용자 지정 코드를 기반으로 할 수 있습니다. LINQ2SQL을 사용하면 쿼리 실행이 지연되는 등의 몇 가지 장점이 있지만 엄격하게 필요한 것은 아닙니다. DAL 외부에서 LINQ를 사용하는 것을 피하는 데는 아무런 의미가 없습니다. DAL을 LINQ2SQL 기반이 아닌 다른 것으로 대체하려는 경우 가능합니다. LINQ 기반 코드가 기대하는 인터페이스를 유지하는 한 괜찮습니다.
EDIT : DAL에 도달 할 때까지는 LINQ2SQL 쿼리가 아니라 LINQ 일뿐입니다. LINQ는 더 나은 것으로 대체되지 않는 이상 언어에서 사라지지 않을 것입니다. LINQ2SQL을 만드는 것은 DAL이 LINQ2SQL로 구현된다는 것입니다. 나머지 코드는이 사실을 알지 못합니다. LINQ2Objects 또는 LINQ2Entities 또는 ...
LINQ2Object의 유효 시점을 LINQ2SQL과 다른 것으로 지정합니다. 내 DAL 외부 LINQ2SQL 및 지연 실행 원인 sonner 또는 나중에 당신이 LINQ2SQL 같은 정적 인 문자열 비교 등 지원하지 않는 뭔가를 할 것이다 그래서 IQueryable –
나는 내가 Helpers.DataContext의 인스턴스를 데이터베이스에 액세스해야의 번호를 가지고있다.
이것은 멋진 분리를 유지합니다.
개인적으로 "기본"쿼리를 만들고 IQueryable을 노출합니다.
내 비즈니스 개체에서 구체적인 결과를 반환하기 때문에 일반적으로 QueryByExpression 스타일 메서드를 내부 전용으로 만든 다음 내 기준에서 전달할 수있는 메서드 스텁을 만들고 쿼리를 처리하는 메서드에서 get 데이터베이스에서 결과를 가져 와서 결과의 IEnumerable을 반환하고 나머지 응용 프로그램에는 컨텍스트가 필요하지 않습니다.
그러나 많은 사람들이 말했듯이 IQueryable을 코드에 노출시키는 것은 끔찍한 일이 아니라 단지 Linq2Sql에 좀 더 묶여 있기 때문에 동의해야합니다.
메서드를 노출하지만 IQueryable 형식을 노출시키지 않는 비즈니스 개체를 만드는 데 신경 쓰지 않는다면 비즈니스 개체를 설정하고 구성하는 것이 더 바람직하다고 느낍니다. 그것도 쉽게 테스트 할 수 있지만, 그것은 나뿐입니다. 재사용을 위해 만들 수도 있고, 버그를 수정하면 2 년 후 코드의 30 개 지점에 버그가 존재하지 않습니다.
그냥 2 센트입니다.
LINQ2SQL의 핵심이고 LINQ2SQL을 매우 훌륭하게 만드는 많은 것을 다시 작성하기 때문에 별도의 비즈니스 개체를 만들 필요는 없습니다.
그러나 L2SQL 코드가 포함 된 정적 클래스로 클래스 라이브러리를 만드는 것이 좋습니다. 따라서 단일 어셈블리를 대체하여 비즈니스 논리를 변경할 수 있다는 장점이 있습니다. 또한 데이터에 액세스하기위한 추가 방법이있는 경우 정적 클래스가 해당 논리에 적합한 장소입니다.
그러나 난 당신의 요구가 좀 더 복잡하고 당신이 자신의 매핑을 만드는 상관 없어 플로리안 동의합니다.
정적 클래스로 것들을 노출하는 것이 좋습니다 않는 것이 좋습니다. ? 이걸로 시험을 치는 능력을 죽일거야. –
최근 프로젝트에서 ASP.NET MVC 프레임 워크와 LINQ-to-SQL을 사용합니다. 이러한 이유로 저는 데이터 레이어의 저장소 패턴에 크게 의존합니다. 이것이 처음으로 LINQ-to-SQL 프로젝트이기 때문에 데이터베이스 스키마는 단일 DataContext 클래스 내에서 표현됩니다. 나중의 프로젝트가 진행되면서 공통된 DataContext를 재사용 할 수 있습니다.
일반적으로 단일 복합 객체를 나타내는 특정 저장소에 구현할 모든 서명을 보유하는 인터페이스를 만듭니다. 해당 인터페이스를 기반으로 프로덕션 용, 테스트 용의 두 클래스를 구현합니다. 모든 LINQ-to-SQL 쿼리는 저장소 클래스에 보관됩니다. 내 컨트롤러 코드에서 데이터 액세스 방법에 대한 리포지토리에 액세스합니다. 내 견해에는 검색어가 포함되지 않습니다. 저장소 메서드를 사용하여 컨트롤러에서 채워지는 사용자 지정보기 모델 클래스를 사용합니다.
DAL DLL에 Linq2SQL을 사용했습니다. 다른 사이트 나 앱이 동일한 데이터베이스에 액세스해야하는 등의 문제와 DLL의 코드를 재사용 할 수있는 문제가 마음에 든다. 그래서 모든 Linq2SQL은이 DAL에 저장됩니다. 이제 Linq 자체에 대한 필요에 따라 내 서비스 및 프리젠 테이션 레이어에서 사용합니다.
Linq2SQL DLL 레이아웃
매핑을 생성하기 Linq에 카탈로그 (SqlRepository)
쓴 서비스 레이어 클래스에 일치하고 적절한를 사용하는 SQL 저장소 클래스에 SQL의 table.columns를 매핑 파일을하면 .dbml Linq Catalog 클래스. 각 SQL 저장소 클래스에 대한
추가 인터페이스 서비스 계층 인터페이스와 직접 작동하므로이
는 SQL 저장소 클래스 앞뒤로 서비스 계층에 전달할 비즈니스 모델을 썼다.
나는 장소 전체에 걸쳐 "모든 장소에"단어를 반복하여 "모든 장소에"있는 효과를 재현하는 방식을 좋아합니다. – harpo