ADO.NET Entity Framework를 사용하여 "쿼리"작성을위한 엄지 손가락 규칙

Question

현재 중간 크기 웹 응용 프로그램의 프로토 타입을 작성 중이며 Entity Framework를 실험 해 보는 것이 좋습니다. 문제는 응용 프로그램의 주요 부분이 데이터 계층 및 논리가 아니기 때문에 Entity Framework를 사용할 시간이별로 없다는 것입니다. 반면에 데이터베이스 스키마는 매우 간단합니다.

내가 직면 한 문제 중 하나는 "쿼리 작성"에 일관된 방법을 찾을 수 없다는 것입니다. 엔티티에

• LINQ LINQ 확장 방법
• 법인 SQL
• 쿼리 빌더

를 사용하여 엔티티에

LINQ : 지금까지 내가 말할 수있는 작업에 대한 4 개의 "인터페이스"가

처음 두 개는 본질적으로 동일하지만 유지 관리 및 일관성을 위해 하나만 사용하는 것이 좋습니다.

나는 그 중 누구도 완전하고 가장 일반적인 것 같지 않다는 사실에 당혹 스럽다. 나는 종종 자신을 궁지에 몰아 넣고 몇 가지 못생긴보고 조합을 사용하여 찾습니다. 내 생각 엔 Entity SQL이 가장 일반적인 것 같지만 문자열을 사용하여 쿼리를 작성하면 한발 뒤로 물이 듭니다. Entity Framework와 같은 것을 실험하고있는 주된 이유는 내가 컴파일 시간을 검사하는 것을 좋아한다는 것입니다.

일부 다른 임의의 생각/문제 :

• 나는 종종 또한 ObjectQuery.Include() 메소드를 사용하지만, 다시는 문자열을 사용합니다. 이것이 유일한 방법입니까?
• ObjectQuery.Execute() (ToList())를 사용할시기는 언제입니까? 실제로 쿼리를 실행합니까?
• 최대한 빨리 (예 : ToList()를 사용하여) 쿼리를 실행해야합니까, 아니면 처음 열거 형을 실행하도록 남겨 두어도 상관하지 않습니까?
• ObjectQuery.Skip() 및 ObjectQuery.Take()는 확장 메서드로만 사용할 수 있습니까? 페이징을 할 수있는 더 좋은 방법이 있습니까? 2009 년이며 거의 모든 웹 애플리케이션이 페이징을 다룹니다.

전반적으로 ORM을 구현할 때 많은 어려움이있는 것으로 알고 있으며, 종종 하나를 절충해야합니다. 반면에 직접 데이터베이스 액세스 (예 : ADO.NET)는 단순하고 간단하며 잘 정의 된 인터페이스 (표 형식 결과, 데이터 판독기)를 사용하므로 누구와 언제 작성하는지에 상관없이 모든 코드가 일관됩니다. 데이터베이스 쿼리를 작성할 때마다 너무 많은 선택을하고 싶지 않습니다. 너무 지루하고 다른 개발자가 다른 방법을 생각해 낼 수 있습니다.

엄지 손가락의 규칙은 무엇입니까?

Answer 1

가능한 한 LINQ-to-Entities를 사용합니다. 또한 확장 된 SQL 스타일 구문과 반대로 람다 형식으로 공식화하려고 시도합니다. 관계를 강화하고 효율성을 높이는 데 문제가있어서 응용 프로그램 코딩 작업을 신속하게 처리해야한다는 것을 인정해야합니다 (예 : Master -> Child 테이블을 수동으로로드해야 할 수도 있음).하지만 EF는 좋은 제품입니다.

나는 당신이 말한 것처럼 지연 입력을 위해 EF의 .Include() 메소드를 사용한다. 상대적으로 사용하기 쉬운 문자열을 식별하는 것 외에는 아무런 문제가 없습니다. 나는 당신이 그런 관계의 컴파일 타임 검사에 열중하고 있는지, 비슷한 모델을 추측한다. Parent.GetChildren()이 더 적절할 수 있습니다.

내 응용 프로그램에서는 일부 "동적"쿼리를 수행해야합니다. 나는 이것을 만나는 두 가지 방법이 있습니다 :

a) 나는 중개자 객체를 만듭니다. ClientSearchMediator는 클라이언트를 이름으로 검색하는 방법을 "알고"있습니다. 그런 다음이를 SearchHandler.Search (ISearchMediator [] 중재자) 호출 (예 :)을 통해 넣을 수 있습니다. 이는 특정 데이터 구조를 대상으로하고 LINQ-to-Entities를 사용하여 결과를 적절히 정렬하는 데 사용할 수 있습니다.

b) 사용자가 자신의 쿼리를 설계 한 결과 (우리 애플리케이션이 제공하는 상위 수준의 도구를 사용하는 경우), eSQL은 이러한 목적에 이상적입니다. 그것은 주사 - 안전하게 만들 수 있습니다.

Answer 2

나는이 모든 것을 다루기에 충분한 지식이 없지만 적어도 약간의 찌르기를 할 것입니다.

왜 ADO.NET이 Entity Framework보다 더 일관성 있다고 생각하는지 모르겠습니다. ADO.NET을 사용하는 방법에는 여러 가지가 있으며, 단일 코드 기반 내에서 일관성이 없어 보입니다.

현재 Entity Framework는 1.0 버전이며 1.0 형식 문제 (불완전한 API 인 &, 누락 된 기능 등)가 있습니다.

포함에 관해서는 열심히로드하는 것을 의미한다고 가정합니다. 여러 사람 (Microsoft 외부)이 "형식 안전"포함을위한 솔루션을 개발했습니다 (Entity Framework ObjectQueryExtension Include와 같은 것으로 검색해보십시오). 즉, 포함은 무엇보다 힌트입니다. 열심히로드 할 수 없으며 IsLoaded() 메서드를 호출하여 요청이 충족되었는지 항상 확인해야합니다. 내가 아는 한, "Include"작업 방식은 다음 버전의 Entity Framework (4.0 - VS 2010과 함께 제공됨)에서 전혀 변경되지 않습니다.

Linq 쿼리가 작성되는 즉시 마지막 순간까지 실행하는 한 그 결정은 상황에 따라 다릅니다. 개인적으로는 그렇지 않을 수 밖에없는 강력한 이유가없는 한 대부분의 경우 구축되는 즉시 실행 하겠지만 반대 방향으로가는 다른 사람들을 볼 수 있습니다.

시장에 성숙한 ORM이 있으며 Entity Framework가 반드시 최상의 옵션은 아닙니다. 대부분의 경우 Entity Framework를 유언장에 맞게 구부릴 수 있지만 다른 ORM과 함께 즉시 제공되는 기능 구현을 마무리 할 수 ​​있습니다.