|
성능 고려사항(Performance Considerations)
성능이 뛰어나고 강력하며 확장 가능한 엔터프라이즈 애플리케이션을 구축하고 유지하는 것이 ORM의 핵심입니다. 다음은 100,000 개 이상의 레코드와 평균 <10ms의 SQL 응답 시간이있는 Entity Framework를 사용하는 관계형 데이터베이스 구현의 라이브 예제입니다. 생성되는 쿼리와 속도에 대한 로그를 확인하십시오.
구체화(Materializing)
구체화를 이해하는 것은 ORM 사용의 중요한 부분입니다. 가능한 한 적은 수의 개체를 구체화하기 위해 쿼리를 작성하는 것은 고성능 애플리케이션을 유지하는 데 중요합니다. EF 및 Dapper에는 쿼리를 메모리로 구체화하는 일반적인 C#식이 있습니다. 두 가지 모두 이를 수행하는 몇 가지 고유 한 방법과 명시적인 호출없이 자동 구체화되는 제약 조건이 있습니다.
Generated SQL (EF Only)
Entity Framework는 특히 Entities SQL (EF 6+ 및 EF Core)이라는 SQL 언어를 작성한 다음 대상 데이터 원본 SQL (MSSQL, MYSQL 등)로 변환됩니다. 따라서 응용 프로그램을 변경하지 않고도 응용 프로그램 계층을 모든 유형의 데이터베이스에 이식 할 수 있지만 잠재적인 성능 문제가있는 쿼리를 쉽게 처리 할 수 있으므로 보다 복잡한 개체에 대한 쿼리를 만들 때 약간의 고려가 필요합니다.
The Practical
보안 및 성능 고려 사항을 염두에두고 ORM이 실제로 빛을 발하고 응용 프로그램 개발 수명주기가 개선 된 몇 가지 범주는 다음과 같습니다.
직원을 유지하는 응용 프로그램을 고려하십시오. 애플리케이션은 다음 속성을 사용하여 dbo.Employee 및 domain.EmployeeType이라는 테이블이있는 데이터베이스에 연결합니다.
dbo.Employee | domain.EmployeeType |
EmployeeId (int) [PK] | EmployeeTypeId (int) [PK] |
EmployeeTypeId (int) [FK] | Value [nvarchar] |
Name (nvarchar) | Active (bit) |
Active (bit) |
Speeding Up New Development
새로운 쿼리를 실행하고 새로운 데이터베이스 테이블과 관련 애플리케이션 모델을 지속적으로 추가하는 데 걸리는 시간을 줄이는 것은 ORM의 가장 큰 이점 중 하나입니다.
Comparison: Select all columns from all employees
ORM (Entity Framework)
ORM (Dapper)
ADO.NET
SQL Script
Application Layer
표시된 것처럼 이것은 ORM에서는 매우 간단한 것을 ADO.NET에는 매우 장황합니다. 가독성이 떨어지고 저장 프로시저에서 애플리케이션으로의 데이터 흐름을 따라갈 수 있는 능력이 약화됩니다. SQL 디버깅은 훨씬 더 많은 시간이 소요되고 실수하기 쉽습니다.
이러한 자세한 정도의 차이는 쿼리가 더 복잡해질수록 길어집니다. 몇 가지 예 :
이러한 쿼리가 존재하고 직원이 추가 요청을 받았을 때 필요한 작업의 차이를 상상해보십시오 (실수 가능성도 있음).
Maintenance Reduction
이전 예제에서 현재 아키텍처 파일은 인덱스별로 바인딩되지 않은 배열을 읽고 있으며 새로운 변경 사항에 매우 취약합니다. 열 유형이 변경되면 어떻게됩니까? 저장 프로시저가 내부에 새 열을 추가하고 인덱스를 엉망으로 만들면 어떻게됩니까? 또한 dbo.Employee 테이블과 상호 작용하고 새 정보가 필요한 모든 단일 저장프로시 저도 업데이트해야합니다.
ORM을 사용하면 모델에 속성을 추가하는 것만큼이나 간단하며, 새 속성은 필요한 전체 응용 프로그램의 모든 단일 쿼리에서 즉시 사용할 수 있습니다.
주의! 여기서는 Database table에 컬럼을 추가해 놓고, 그 컬럼을 이용하기 위해 모델에도 Alias 프로퍼티를 추가해서 사용하는 것입니다. 만약, Code-first를 이용하고, 히스토리를 이용하고 있다면, 새로 추가된 컬럼을 database에 반영을 시켜준 후 사용해야합니다.
직원 정보를 필요로하는 유사한 쿼리가 많이 있다고 상상해보십시오. 애플리케이션이 커짐에 따라 발생하는 데이터베이스 열 변경은 Employee 모델에서 속성을 추가/업데이트하기만 하면됩니다. 모든 단일 쿼리는 새 정보를 포함하도록 자동으로 업데이트됩니다. 하지만, .Select()를 이용해 특정 상점 정보를 선택하는 쿼리는 제대로 변경되지 않은 상태로 유지됩니다.
또한, ORM의 강력한 형식 모델을 사용하므로 인해 데이터베이스와 응용 프로그램 간의 결합 된 관계에서 인덱스, 열 형식 불일치 또는 저장 프로시저 결과 집합 불일치로 인한 사고가 발생하지 않습니다. 수정되는 파일이 적고 오류 가능성이 적으므로 변경 영향이 줄어 듭니다.
EF Only
글로벌 쿼리 필터링은 실행중인 쿼리에 추가되는 'middleware'쿼리 역할을합니다. 엔티티의 소프트 삭제를 허용하는 위의 직원 및 직원 유형 테이블을 고려하십시오. 전역 쿼리 필터는 필요에 따라 재정의 할 수있는 모든 쿼리에 .Where (employee => employee.IsActive)를 추가 할 수 있습니다. 이 두 가지 모두 개발자의 실수를 방지하여 유지 관리를 줄이고 개발 속도를 높입니다.
소유 한 엔티티는 상위 개체에 연결될 때만 생성되도록 설정할 수 있습니다. 자체 테이블이 필요하지 않은 일반적인 항목 그룹 속성을 줄이는 데 자주 사용됩니다. 아래 모델을 고려하십시오.
Name 클래스는 Employee 및 ExternalNewsletterSubscriber 모두에서 재사용되며 Name 속성은 데이터베이스의 적절한 소유자 테이블에 매핑됩니다. 여기에서 Owned 대해 자세히 알아보십시오.
Integration Testing
EF는 복잡한 비즈니스 로직에 대한 통합 테스트를 가능한 한 쉽게 작성할 수 있는 in-memory 데이터베이스 기능을 제공합니다. 일반적으로 테스트를 위해 데이터베이스가 필요할 때 SSDT 프로젝트에서 직접 구축됩니다. EF의 in-memory 데이터베이스를 사용하면 테스트가 실행되는 동안 각 통합 테스트에서 자체 원자 데이터베이스를 가질 수 있습니다. 모의 작업이나 기존 데이터 없이도 기존 애플리케이션 코드와 원활하게 작업 할 수 있습니다.
Some Notes
보안과 성능을 염두에두면 Entity Framework와 Dapper는 모두 응용 프로그램 개발 수명주기를 개선 할 수있는 엄청난 기회를 제공합니다. 새로운 개발 속도를 높이고 유지 관리 및 버그 수정 시간을 줄이며 강력한 통합 테스트를 제공함으로써 ORM은 기존 및 신규 개발의 애플리케이션 라이프 사이클에서 많이 고려되어야합니다.
Additional Resources
|