Entity Framework를 사용해야합니까?

현재 다음과 같은 스택이 있습니다.

• VS 2005
• 웹 양식
• SQL Server 2005
• IIS 6

우리는 이것으로 전환 할 계획입니다.

• VS 2010
• MVC 및 웹 양식
• SQL Server 2008
• IIS 7

내 질문은 VS 2010으로 MVC로 옮길 때 Entity Framework (또는 다른 ORM), 마이크로 ORM ( Massive 등 ) 또는 일반 SQL 을 사용해야 합니까?

VS 2010에 대해 읽은 모든 자습서는 모두 데이터 트랜잭션에 Entity Framework를 사용하는 데 적합하지만 가까운 미래 (5 년 이상) 동안 진행될 예정입니까?

중요한 경우, 고객의 응용 프로그램은 10-1,000 명의 활성 사용자를 가질 수 있습니다.

최근에 인라인 SQL 쿼리 사용에서 EF 사용으로 전환했으며 내가 찾은 내용은 다음과 같습니다.

찬성

• DAL을 작성하는 것이 훨씬 빠릅니다 (SQL 쿼리를 작성하지 않는 것이 좋습니다!)
• 유지 관리가 훨씬 쉬움
• 더 이상 인라인 SQL 문을 작성하기 전에 입력을 구문 분석 할 필요가 없습니다. 이는 SQL 주입 공격의 가능성이 적다는 것을 의미합니다 (물론 쿼리에 따라 가능하지만 가능성은 훨씬 적음)

단점

• 여러 데이터베이스를 확장 할 수 없습니다 ... 최소한 쉽지는 않습니다
• 모든 엔티티 (테이블, 뷰 등)에는 기본 키가 필요합니다.
• 100 개 이상의 필수 열 테이블 (내 테이블 디자인이 아님)에서 단일 열을 업데이트하려면 100 개 열을 모두 아래로 당겨 업데이트해야합니다. 또는 저장 프로 시저를 사용하십시오.
• 새 레코드가 추가 된 후 SQL 서버에 정의 된 일부 기본값과 엔티티 모델로 가져 오지 않는 문제가 있습니다. 일반적으로 이것은 계산 된 값 또는 INSERT 트리거에 추가되는 값입니다
• 간혹 SQL 쿼리가 잘못 작성되어 실행 속도가 느립니다. 느리게 실행되는 쿼리가있는 경우 SQL 추적을 실행하여 EF가 수행중인 작업을 확인하십시오. 해당 쿼리를 SP 또는보기로 다시 작업 할 수 있습니다. 그러나 이것은 자주 발생하지 않습니다.
• SQL Server에 외래 키가 정의되어 있지 않은 테이블 간의 연결을 만들 때 몇 가지 문제가 발생했습니다. 일반적으로 1:0-1EF가 사용하려는 관계 를 만들려고하기 때문에1:0-*

나는 EF 전문가가 아니므로 아마도 몇 가지를 놓친 것 같습니다. 이들은 인라인 SQL에서 Entity Framework로 전환 할 때 내가 과거에 만난 것으로 알고있는 항목입니다. 나는 전환을하게되어 기쁘지만, 그 단점 때문에 EF를 싫어 한 적이있다.

Entity Framework는 생산성 도구입니다. 하지 말아야 할 충분한 이유가 없다면 (EG, SQL 2000을 사용 중이거나 기술을 강화할 시간이 없다면) 최상의 도구를 사용하십시오.

즉, 엔터티 개념이 MVC 패턴의 모델로 매우 잘 변환된다는 것을 알았습니다. 모델 및 테이블과 1 : 1 관계를 갖는 것은 좋지 않지만 엔터티 측면에서 생각하면 깔끔한 디자인, 읽기 쉬운 코드 (특히 LINQ)를 생성하는 경향이 있습니다.

Entity Framework는 Microsoft에서 적극적으로 지원합니다. "X 년 지속될 것"이라는 마법의 수정 구슬이있는 사람은 없습니다. 앞으로 5 년 안에 엔터티가 죽을 것이라고 믿을 이유가 없습니다.

또 다른 잠재적 인 솔루션은 VS와 함께 제공되지 않는 대체 Entity Framework 라이브러리를 사용하는 것입니다. 웹에는 몇 가지가 있습니다.

Microsoft가 자체 "공식"프레임 워크를 발표하기 전에 Entity / 3 레이어 프레임 워크 개념은 오랫동안 존재 해 왔으며 다른 많은 개발자와 마찬가지로 여러 사용자 정의 라이브러리와 함께 작업했습니다.

찬성

Microsoft의 지속적인 라이브러리 / 프레임 워크 변경없이 Entity (DAL) 프레임 워크의 이점을 누리십시오.

여러 dtabase 브랜드를 사용하는 것과 같이 기존 공식 라이브러리에서 사용할 수없는 기능을 라이브러리에 추가

단점

라이브러리 나 도구를 지원해야합니다. 엔티 테를 생성하는 엔터티 생성기 코드 도구를 사용하는 것이 매우 일반적입니다.

문제와 기존 솔루션을 기반으로 아키텍처 결정을 내려야합니다. 모든 기술과 마찬가지로 장단점이 있습니다.

필자는 개인적으로 새로운 개발을 위해 엔티티 프레임 워크를 사용하지만 기존 코드 작동을 다시 작성하지는 않습니다. 그런 다음 미래의 위임 속도를 얻지 만 코드를 변환하는 데 많은 시간을 투자 할 필요는 없습니다. 이러한 접근 방식의 단점은 일관성을 줄이는 것입니다.

귀하의 상황에서 Entity Framework를 확실히 사용하려고합니다 .MVC와 잘 작동한다는 것을 알았습니다.
여기에 몇 가지 진정한 이유와 조언이 있습니다.

• Linq는 사용하기에 즐겁고 지연된 실행도 매우 유용합니다.
• 모델을 생성 할 수 있습니다 (그러나 mvc와 함께 사용하는 경우 데이터 모델과 함께 뷰 모델을 사용하는 것이 좋습니다). 이렇게하면 automapper 를 사용 하여 변경 사항을 다시 매핑 하여 매핑 하면 유효성 검사 및 모델 바인딩이 훨씬 쉬워집니다. 데이터 모델).

그러나 ORM 사용에 대해 알아야 할 사항이 많이 있습니다.

• 컨텍스트가하는 일 (엔티티 추적)
• 컨텍스트가 작업 단위로 사용되어야 함
• 동시성에 대해 기억하십시오. EF는 객체가 오래되었을 때 알려줄 수 있지만 (타임 스탬프 등을 유지해야 할 때) 요청에서 동시성을 올바르게 처리하려는 경우 까다로울 수 있습니다.

고려할 사항

• 트리거와 ORM이 함께 작동하지 않으므로 대신 ORM 이벤트를 사용하십시오.
• 모든 테이블에 promary 키가 있는지 확인하십시오.

기존 데이터베이스가 있더라도 코드 우선 접근 방식을 강력히 권장합니다.

• 규칙은 데이터베이스를 변경할 때 매핑이나 클래스를 재생성 할 필요가 없음을 의미합니다.
• 모델에 유효성 검사 및 기타 논리를 배치하는 것이 더 쉽습니다.
• 거대한 기존 데이터베이스가있는 경우 코드 생성기를 사용하여 만들 수 있습니다.