정의 된 관계가없는 데이터베이스에서 ORM을 사용합니까?

Question

기본 키가 어느 정도 정의되어있는 100 개 이상의 테이블로 구성된 데이터베이스 (MSSQL 2005)를 생각해보십시오. 테이블 간에는 '관계'가 있지만 외래 키 제약 조건에는 적용되지 않습니다.

내가 다루고있는 일반적인 유형의 테이블의 다음 단순화 된 예를 고려하십시오. 사용자와시 및 도의 테이블 간의 명확한 관계입니다. 그러나 중요한 문제는 테이블과 명명 규칙에서 일치하지 않는 데이터 유형입니다. MVC의 점포 디자인이 유사한이기 때문에이 데이터 소스를 사용

User: 
    UserRowId [int] PK 
    Name [varchar(50)] 
    CityId [smallint] 
    ProvinceRowId [bigint] 

City: 
    CityRowId [bigint] PK 
    CityDescription [varchar(100)] 

Province: 
    ProvinceId [int] PK 
    ProvinceDesc [varchar(50)] 

내가 (ASP.net MVC에서) 응용 프로그램의 재 작성을 고려하고있다. 그러나 나는 개념 단계의 증명을 통해 갈 것이고, 이것이 내가 만난 걸림돌 중 하나이다.

1. 쉽게 사용할 수 있고 그 이유는 무엇입니까?

2. ORM을 고려해야합니까? (내가이 질문을하는 이유는 대부분의 설명과 튜토리얼은 모두 비교적 깨끗하게 설계된 기존 데이터베이스 또는 새로 작성된 데이터베이스와 작동하기 때문이다. 따라서이 문제로 앞으로 나아갈 길이 열심히 노력하고있다)

3. 엄청난 양의 기존 SQL 쿼리가 있습니다. 데이터 마커 (예 : IBatis.net)가 쉽게 수정하여 이미 수행 한 투자를 재사용 할 수 있기 때문에 더 적합할까요? 나는이지도의 문제가 그 인상을하지만 -

나는 ORM이 사용될 수 있다는 것을 나에게 나타내는 SO에 this question을 발견했다?

참고 : 현재 개체 모델은 존재하지 않았으므로 명확하게 정의되지 않았습니다. 기존 시스템은 거의 모든 것을 SQL로 처리했거나 기능을 완료하기 위해 지나치게 복잡하고 많은 쿼리로 구성되었습니다. 나는 꽤 많은 멍청이이고 ORM과 MVC에 대한 경험이 거의 없다.

Answer 1

나는 Ben에 동의합니다.

저는이 상황에서 램프 스택을 사용했습니다. 오래된 더러운, bady 코드화 된 웹 사이트는 스크래치를 발생시킬 필요가있었습니다. 글자 그대로 최악의 데이터베이스였습니다. 블라인드 SQL 실행 라인과 결합되었습니다.

직업? SQL을 매우 빨리 제거하고 추상화로 대체하십시오. 어떤 ORM인가? 기존 ORM을 사용하여 나쁜 데이터베이스 (대부분의 데이터베이스)를 소급하여 뒤집어 쓰는 것이 나쁜 소식이라는 것을 알았습니다. ORM에 문제가 있다고 생각합니다. 데이터베이스/스토리지 문제를 응용 프로그램에 더 가깝게 옮깁니다.

내 솔루션 : 무슨 일이 벌어 졌는지 알아보기 위해 기존 데이터베이스 상태 만 사용한 반사 형 ORM. 모든 선택, 삽입, 업데이트 및 사용되지 않은 뷰/저장 프로 시저가 cruddy 데이터베이스를 마스크합니다. 그것은 linq-esque API에 의해 구동되며 무서운 SQL을 다시 작성합니다. 약 100klocs의 SQL 문을 2klocs 미만으로 끓였습니다.

pros : 점차적으로 데이터베이스를보기 및 절차 뒤에 더 나은 구조로 이식 할 수 있습니다. IMHO이게 어떻게 모든 데이터베이스가 구성되어야하는지, SP와 뷰가 제공하는 추상화를 최대한 활용해야합니다. 나는 테이블에 대해 직접적으로 하나의 SQL 문 (또는 SQL으로 위장한 ORM)을보고 싶지 않다.

그건 내 이야기입니다. 데이터베이스를 먼저 다시 작성하지 않고 ORM을 믹스에 넣지 않고 훨씬 복잡한 작업을 수행하면서 기존의 쓰레기 데이터베이스 위의 멋진 추상화를 구현할 수 있습니다.

해킹, 의심의 여지하지만, 잘 나는 어쨌든 처음부터 데이터베이스를 설계 할 수있는 프로젝트에 사용하고 그렇게 작동)

Answer 2

기존 스키마를 유지하고 훨씬 더 구조화 된 orm 패턴으로 혼란시키려는 노력의 양은 아마도 크고 복잡 할 것입니다. 전체 시스템을 다시 작성하고 이전 버전을 폐기하는 경우 데이터 모델을 작성하여 새로운 데이터베이스와 클래스 세트를 작성한 다음 linq2sql을 사용하고 데이터 마이그레이션 스크립트를 작성하여 이전 스키마의 데이터를 새 스키마로 이동하십시오 . 그렇게하면 복잡한 fiddly 코드가 모두 마이그레이션에 포함되므로 구조화 된 클래스 모델과 잘못 설계된 db 간의 복잡한 매핑을 유지 관리해야 할 필요가 없습니다.

Answer 3

우리는 끔찍한 스키마 디자인이 문제에 직면했습니다 (무작위로 기본 키가 있고 전혀 외래 키가 없으며 잘못 설계된 테이블 일뿐입니다.) 다른 사용하는 엔티티 프레임 워크 4

I을 자 NHibernate를 사용하여 모델링 한 시도 -

우리는 기술 선택의 고급 스러움이 있고, (귀하의 질문에 무관) MVC2 프론트 엔드를 가서 2 개의 devs 물적 분할했다 우리는 도메인 모델에서 우리가 원했던 것을 강력하게 생각하고, 처음에는이를 모델링하여 (데이터베이스에 의해 제한되기를 원하지 않음) 스키마의 관점에서 볼 때 'User'객체가 실제로 5 개의 테이블을 스팬하고, 우리는 많은 비즈니스 로직을 캡슐화하여 도메인 모델이 불안정하지 않게하고 User 객체에 만족하면 ORM을 플러그인하는 프로세스를 시작했습니다.

나는 주저없이 (NH와 EF4) 두 가지 경우 모두에서 구현을 구두 뿔에 고정하기 위해 모델에 대한 타협점을 말할 수 있습니다. EF4에서 예제를 드리겠습니다. 가장 밀접하게 연관된 것이므로 다른 것들은 다른 ORM과 관련 될 수 있습니다.

개인 세터

아니 -하지 EF4와 당신의 인생에. 귀하의 부동산은 반드시 공개되어야합니다. 래퍼 개념과 '매핑'조회를 얻기 위해 시도가 있었다 - 해결 방법 아니, 다시

열거 (예를 들어, 귀하의 DB에서오고 있었다 속성 래퍼를 생성)가 있습니다 int 열거 형 모델에 DB에서. 우리는 우리가 사용자의 매핑을 완료했던 지점에 도착하는 두 가지 방식으로 잠시 동안 인내

는 성과 및 결과는 우리가 너무 많은 우리의 도메인 모델을 손상했다이었다 방법.

어디로 갔습니까?

Linq to SQL. 우리 고유의 매핑 레이어. 그리고 우리는 결코 되돌아 보지 못했습니다. 절대적으로 환상적입니다. Dal 레이어에서 Dto 객체를 가져 와서 (우리가 지정한대로) 도메인 모델에 맵핑 레이어를 작성했습니다.

ORM에 대한 조사에 대해 행운을 빈다. 내가 기초를 닦아 낼 수있는 적절한 스키마가 있다면 ORM을 조사해 보는 것이 좋겠지 만, 끔찍한 스키마로 인해 우리 자신을 굴리기가 더 쉬웠다.

건배, 테리