CodeFirst는 대규모 응용 프로그램을위한 것입니까?

나는 Entity Framework, 특히 EF 4.1을 읽고이 링크 ( http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity- framework-4.aspx ) 및 Code First에 대한 안내서입니다.

깔끔한 것을 알았지 만 궁금한 점이 있습니다. Code First는 많은 계획없이 바로 뛰어들 수있는 대규모 개발을위한 솔루션입니까? 아니면 실제로 대규모 응용 프로그램에 사용됩니까?

나는 약간의 혼란 스러울지도 모르지만 Hanselman과 Gutherie의 게시물을 읽은 다음 Entity Framework에 대한 Julia Lerman의 책 을 읽으면 코드가 처음으로 정말 힘들었습니다. 수년간의 응용 프로그램 구축 과정에서 프로세스와 선택에 따라 많은 경로를 밟았으며 응용 프로그램을 작성할 때 데이터 중심의 관점에서 볼 때 훨씬 더 많은 성공을 거두었습니다.

여기서는 업무용 응용 프로그램에 대해 이야기하고 있습니다 ... 여기에는 소프트웨어 솔루션이 필요한 비즈니스 문제 나 프로세스가있을 때입니다. 어떤 방식으로 관리해야하는 데이터가 있습니다. 데이터와 데이터와의 관계 및 비즈니스 내에서 사용되는 방법을 아는 것이 좋습니다. 따라서 해당 데이터를 모델링 한 다음 그 주위에 응용 프로그램 / 솔루션을 만듭니다. 내 경험에 따르면, 나중에 생각할 때 데이터를 사용하여 응용 프로그램을 만들기 시작하면 결국 무언가가 빠져 나온 다음 리팩토링이 발생합니다 (많은 경우-MAJOR 리팩토링).

소규모 응용 프로그램은 예외 일 수 있지만 데이터 중심 방식을 계속 사용할 것입니다.

대규모 엔터프라이즈 프로젝트에서 CodeFirst를 사용할 수없는 이유는 알 수 없습니다. 필자는 여러 프로젝트에서 EF CodeFirst를 사용한다고 말하고, 하나는 내 EF CodeFirst 모델로 데이터베이스를 생성하고, 두 번째는 EF CodeFirst를 기존 데이터베이스에 매핑합니다.

내 경험상, 대규모 프로젝트에서 CF가 얼마나 효과적인지는 데이터 계층이 비즈니스 계층에서 얼마나 추상화되어 있는지에 크게 좌우됩니다.

예를 들어, 내 프로젝트 중 하나에서 비즈니스 계층은 linq를 통해 데이터베이스를 직접 호출합니다. Linq를 사용하여 데이터베이스 계층을 추상화하고 CodeFirst를 사용하여 POCO를 데이터베이스 스키마에 매핑합니다. 이 경우 CodeFirst는 DB 규칙 (관계 및 테이블 이름)과 C # 클래스 이름 간의 차이를 유지하는 작업을 훨씬 간단하게 수행하며 비즈니스 계층이 데이터베이스와 상호 작용하는 방식에 크게 영향을주지 않으면 서 데이터베이스를 변경할 수 있습니다.

그러나 다른 프로젝트에서는 제네릭이 아닌 리포지토리 패턴에 대한 데이터베이스 액세스를 추상화했으며 내 리포지토리의 Get * 메서드는 데이터베이스에서 쿼리를 실행하는 전적인 책임이 있으며 실제 객체 ( IQueryable<T>s가 아님)를 반환합니다 . 이 경우 리포지토리 메서드는 DB 엔터티를 POCO 엔터티로 변환하고 있으며이 경우 CodeFirst는 수명이 짧고 비즈니스 계층 C # 클래스로 빠르게 변환되므로 CodeFirst는 많은 이점을 제공하지 않습니다.

궁극적으로 팀 구성 방식 및 DBA ​​이외의 엔지니어가 데이터베이스 스키마를 수정하는 데있어 팀 (또는 노인)이 얼마나 편한지, 코드 구조에 영향을 줄 스키마 변경 정도에 따라 달라집니다. CodeFirst가 기존 데이터베이스에 매핑되면 속성 이름의 전역 이름을 바꾸지 않고도 속성을 새 열 이름으로 다시 매핑하는 것이 쉽지 않습니다. 특히 이해하기 쉬운 이름에 대해 이야기 할 때 특히 중요합니다. C # 속성이 아닌 데이터베이스 필드의 경우 또한 C # 엔터티를 완전히 리모델링하지 않고 새 데이터베이스 필드에 대한 코드 지원을 추가하는 것도 사소한 일입니다 (기존 데이터베이스에서 Linq-to-sql을 EF CodeFirst로 남겨둔 이유 중 하나).

Code First는 대규모 응용 프로그램에는 적합하지 않습니다. 대규모 앱 개발 소요 시간은 매우 큽니다.

일반적으로 비즈니스 앱의 수명주기는 다음과 같습니다.

1. 버전 1이 생산 중입니다
2. 버전 2는 베타 버전입니다
3. 버전 3은 현재 개발 중입니다
4. 버전 4가 계획 중입니다.

그리고 다른 교차 응용 프로그램 통신 브리지, 일부 예약 된 작업, 일부 타사 통합, 모바일 등의 다른 통신 장치를위한 웹 서비스가 있습니다.

결국 Code First는 Entity Model의 ObjectContext를 사용하며, 이전 EF는 EDMX를 생성하고 EntityObject와 함께 ObjectContext를 사용하는 것이 모든 것이 충분했습니다. 텍스트 템플릿을 쉽게 사용자 정의하여 코드를 생성 할 수 있습니다. ObjectContext 구현에서는 변경 감지 방법이 느리지 만 프록시를 생성하는 대신 EF 팀은 먼저 코드를 다시 작성하는 대신 변경 감지 속도를 쉽게 개선 할 수있었습니다.

자동화 된 마이그레이션

자동화 된 마이그레이션은 이론적으로는 좋지만 실제로 사용하면 실제로는 불가능합니다. 프로토 타이핑에만 유용하며 빠른 데모를 개발합니다.

코드 우선 마이그레이션은 이러한 시스템에 전혀 적합하지 않습니다. 버전 1과 버전 2는 대부분 동일한 데이터베이스와 통신합니다. 버전 3과 버전 4는 일반적으로 준비 중이며 데이터베이스가 다릅니다.

데이터베이스 우선

Database First는 실용적인 접근 방식으로 SQL 스크립트를 쉽게 비교하고 시각화하고 유지 관리 할 수 ​​있습니다. DBA는 쉽게 작업 할 수 있습니다.

텍스트 템플릿

성능 문제를 해결하는 사용자 지정 구현이 거의없이 EDMX 및 ObjectContext를 쿼리하고 생성하기 위해 자체 텍스트 템플릿을 만들었습니다. 여러 버전의 응용 프로그램이 문제없이 동일한 데이터베이스와 통신합니다.

나에게 .tt 파일을 마우스 오른쪽 버튼으로 클릭하고 "사용자 정의 도구 실행"을 클릭하면 클래스 작성, 모델 구성 및 작성이 훨씬 빠르고 쉬운 단계입니다.

일반적으로 대규모 프로젝트의 경우 데이터베이스가 이미 생성되었습니다. 레거시 데이터베이스이거나 성능을 위해 유능한 dba에 의해 생성 되었기 때문입니다. CodeFirst의 유일한 이점은 EF 엔터티를 사용하지 않고 POCO를 사용하려는 경우입니다.

"Code First"는 더 "민첩한"(해당 용어를 과도하게 사용하지 말고 반드시 방법론을 의미하지는 않음) EF를 사용하기위한 것입니다. 기존 데이터 모델 또는 기존 데이터; Django 또는 PHP 프레임 워크 또는 Rails를 사용하여 일반적으로 데이터 모델을 중심으로 응용 프로그램을 작성하는 대신 코드의 일부로 데이터 모델을 만드는 프레임 워크 지침을 따를 때 사용할 수있는 응용 프로그램 종류 물건을 다루는 Microsoft의 방법.

질문에 대답하기 위해 나는 '아니요'라고 말할 것입니다. 기존 데이터가 이미 있고이를 처리 할 응용 프로그램을 만드는 경우 Code First는 그다지 의미가 없습니다. 그러나 Code First EF는 물론 EF를 전혀 사용하지 않았습니다. 코드에 대한 느슨하게 결합 된 접근법 인 것처럼 보이며 항상 유익합니다. Code First를 사용하고 클래스를 기존 데이터 모델을 가리킬 수 있다고 가정하면 (모델을 강제로 생성하는 대신) Code First 접근 방식을 사용하면 일반적인 "크래프트"사용없이 올바르게 추상화되고 테스트 가능한 코드를 작성할 수 있습니다. Entity Framework (즉, 생성 된 메타 클래스).

실제로 큰 프로젝트에서 코드 우선은 의미가 없습니다.

실제로, 프로젝트가 실제로 커지면 종종 관심사를 엄격하게 구분합니다. C # 코드 작성, 데이터베이스 디자인, HTML / CSS 작성 및 Photoshop에서 시각적 디자인을 수행하는 사람은 동일하지 않습니다. 대신 데이터베이스 설계는 데이터베이스 관리자 (또는 최소한 자신의 직업을 알고있는 전담 직원)가 수행합니다.

데이터베이스는 데이터베이스, SQL 및 관리 및 데이터베이스 디자인 도구에 익숙한 사람이 설계 했으므로 Entity Framework를 사용하여이 사람을 보는 것이 이상합니다.

또한 Entity Framework가 데이터베이스를 올바르게 디자인 할만큼 강력한 지 확실하지 않습니다. 인덱스는 어떻습니까? 제약이 있습니까? 견해?

코드는 먼저 대규모 시스템에서도 실행 가능합니다. 생성 후 모델을 검사하고 원하는 DB 모델에 도달 할 때까지 유창한 API를 사용하여 다시 매핑하십시오.