공급자 독립형 DAL (.Net)을 디자인하는 방법

Question

현재 쿼리 작성기 응용 프로그램을 개발 중입니다. 기본적으로 SQL에 대한 지식이없는 사용자가 데이터베이스에 대한 다양한 쿼리를 정의 할 수있는 간단한 그래픽 인터페이스입니다 (조인, 선택, 업데이트 , 삽입, 삭제). 나는 닷넷 3.5를 사용할 것이다. 내 응용 프로그램은 여러 데이터베이스를 지원해야하며 MS-SQL Server, MySQL 및 Oracle과도 작동해야합니다. 에 대한 관련 힌트 또는 링크와 관련하여 독자적인 DAL을 설계하는 방법에 대해 감사드립니다.

사용자는 데이터베이스 서버, 현재 서버의 데이터베이스를 선택하고 연결 자격 증명을 제공하며 다양한 테이블을 선택하고 일련의 콤보 상자를 사용하여 쿼리를 정의한 다음 유효하면 마지막으로 쿼리를 실행합니다. 물론 DAL에서 각 DB 공급자에 대한 메서드를 갖고 싶습니다. 나는 공장 패턴의 라인에서 뭔가를 생각하고있다.

참고 :이 프로젝트는 간단한 학교 프로젝트이므로 결과 쿼리의 보안이나 성능에는 관심이 없습니다.

업데이트 : 당신이 제공 한 매우 중요한 연구 결과와 함께 DbProviderFactory를 사용하기로 결정했습니다. ORM은 흥미로울 것입니다. 그러나 쿼리 분석기/빌더를 원할 때부터 필자는이 쿼리 분석기/빌더를 사용하는 지점을 보지 못했습니다. 따라서 DbProviderFactory 및 관련 클래스를 사용하는 방법에 대한 자세한 자습서를 알려 주시면 감사하겠습니다.

Answer 1

System.Data.Common.DbProviderFactories 클래스를 사용하여 제네릭 ADO.NET 클래스를 생성하는 것이 좋습니다.

지원하려는 데이터베이스에 대해 더 많은 .NET 공급자를 찾았 으면 응용 프로그램 경로에 공급자 DLL을 놓고 app.config 파일에서 공급자의 DbProviderFactory에 대한 참조를 추가하기 만하면됩니다. 사용자가 사용할 공급자를 선택할 수 있습니다.Obtaining a DbProviderFactory (ADO.NET)

내가 전에이 방법을 사용하고 사소한 구성 변경과 같은 프로젝트에 MSSQL과 SQLite는 지원 할 수있었습니다 :

다음은 주제에 대한 MSDN 문서입니다.

확실하지가 비록 쿼리 빌더 응용 프로그램을 위해 잘 작동 있을지 ...

Answer 2

ADO.NET Entity Framework (.NET 3.5 SP1부터 사용 가능)는 데이터베이스 종속 SQL을 엔티티 SQL 언어로 추상화하기 때문에 좋은 선택이라고 생각합니다.

Answer 3

은 당신이 놀랄 수도 있지만 매우 간단한 제공 독립적 인 DAL은 달성 할 수 있습니다

평범한 구식 데이터 집합 및 DataTable을.

Answer 4

합리적으로 복잡한 쿼리를 시각적으로 편집하는 것이 매우 번거롭다는 것을 말해야합니다. 또한 사용자가 비주얼 디자이너를 사용하여 데이터를 삽입/삭제할 수있게하는 것이 발에서 자신을 쏠 수있는 확실한 방법입니다. Management Studio의 크기가 축소 된 버전, 기본 SQL과 제한된 서버 사용자에 대한 지식이 훨씬 뛰어납니다.

아직이 응용 프로그램을 디자인하는 경향이 있다면, 당신은 NHibernate가 필요합니다. 보다 정확하게는 Criteria Queries이 작업을 수행합니다. 필요한 작업에 매우 가깝게 매핑되기 때문입니다.

Answer 5

대부분의 ORM (Object-Relational Mapper)은 다양한 데이터베이스 유형과 대화하는 방법을 알고 있습니다.

사용자가 자신의 검색어를 작성할 수 있도록 허용하려면 다음 사항에 매우주의해야합니다. 실수로 사용자가 악의적 인 쿼리를 만들 수있는 것은 아닙니다 (문제 일 수는 있지만). 사용 가능한 모든 서버 리소스를 사용하고 데이터베이스에 대한 효과적인 서비스 거부를 생성하는 쿼리를 작성하는 것은 놀랍도록 쉽습니다.

Answer 6

나는 이것이 당신의 탐구에 도움 있는지 확실하지 않습니다,하지만 마음은 한가지 나는 최근에 오히려 배운했다 데이터 모델의 고유 식별자 구현을 데이터 계층 외부로 직접 전파하지 않고 추상화로 래핑하는 것. 데이터베이스 테이블에 ID 열에서,

public interface IModelIdentifier<T> where T : class 
{ 
    /// <summary> 
    /// A string representation of the domain the model originated from. 
    /// </summary> 
    string Origin { get; } 

    /// <summary> 
    /// The model instance identifier for the model object that this 
    /// <see cref="IModelIdentifier{T}"/> refers to. Typically, this 
    /// is a database key, file name, or some other unique identifier. 
    /// <typeparam name="KeyDataType">The expected data type of the 
    /// identifier.</typeparam> 
    /// </summary> 
    KeyDataType GetKey<KeyDataType>(); 

    /// <summary> 
    /// Performs an equality check on the two model identifiers and 
    /// returns <c>true</c> if they are equal; otherwise <c>false</c> 
    /// is returned. All implementations must also override the equal operator. 
    /// </summary> 
    /// <param name="obj">The identifier to compare against.</param> 
    /// <returns><c>true</c> if the identifiers are equal; otherwise 
    /// <c>false</c> is returned.</returns> 
    bool Equals(IModelIdentifier<T> obj); 
} 

귀하의 비즈니스 로직 계층, 예를 들어 (int의 고유 식별자 주위에 전달 과거에 할 수 있습니다 : 예를 들어, 여기에 모델의 식별자를 랩하는 인터페이스입니다), 지금과 같은 전달됩니다

public IPerson RetrievePerson(IModelIdentifier<IPerson> personId) 
    { 
     /// Retrieval logic here... 
    } 

데이터 층은 IModelIdentifier<Person>를 구현하고 물리적 모델의 고유 식별자와 내부 데이터 형식을 채우는 클래스가됩니다. 이렇게하면 int 키 식별자를 Guid으로 바꿀 수있는 등 비즈니스 계층을 데이터 계층에서 변경하지 못하게됩니다.