2009-09-10 3 views
1

다음 코드를 사용하여 개체와 모든 속성을 db에 저장합니다. 모든 비즈니스 객체에서 save 메소드를 작성하지 않아도됩니다. 내 기본 클래스의 코드는 다음과 같습니다리플렉션을 사용하여 기본 클래스에서 속성 이름과 값을 가져올 수 있습니까?

public void Save() 
    { 
     List<SqlParameter> Params = new List<SqlParameter>(); 
     foreach (PropertyInfo Property in this.GetType().GetProperties()) 
     { 
      if (Property.CanRead)     
       Params.Add(new SqlParameter(Property.Name,Property.GetValue(this,null)));     
     } 
     Execute<int>(SaveProcedure, Params.ToArray());   
    } 

이 좋은 연습 아니면 내가 반사를 사용하고 내가 만든 각 개체의 저장 방법을 생성하지 더 나을 것?

다른 아이디어 나 제안을 보내 주시면 감사하겠습니다.

+0

데이터베이스에 개체의 속성 이름과 일치하는 필드가없는 경우 몇 가지 문제가 발생할 수 있습니다. – Frinavale

+0

빠른 답변을 보내 주셔서 감사합니다. 나는 LinqToSql을 살펴보고 이것을 완전히 벗어나게 할 것입니다. – Mike

답변

7

당신이 자신의 기본 인 ORM을 만드는 것처럼 보입니다. LinqToSql 또는 과 같이이 작업을 수행하기 위해 특별히 .NET 프레임 워크 용으로 작성된 완벽한 기능의 매퍼를 사용 해본 적이 있습니까?

0

나는 반성에 크게 의존하는 사람으로서 부적절하다고 생각하지 않습니다. 그러나 조심스럽게 트레이드 오프를 고려해야합니다. 리플렉션을 사용하면 컴파일 시간 검사에서 제외되므로 조기 오류 탐지를 의미하지 않습니다. 따라서 리플렉션을 사용하면 코드를 더 잘 관리하고 성능을 신경 쓸 필요가 없다고 생각하면 리플렉션을 사용하면 문제가되지 않습니다.

리플렉션을 사용할 때마다 문제가 일찍 발견 될 수 있도록 충분한 테스트를 작성해야합니다.

다만.

0

반사는 실제로 프로그램 분석에만 사용됩니다. 이 프로그램을 사용하면 프로그램의 성능과 증명 가능성에 심각한 심각한 부작용이 있습니다. 그렇다고해서 프로덕션 애플리케이션에서 리플렉션이 적절한 경우가 아니라는 것을 의미하지는 않습니다.하지만이 경우 중 하나라고 생각하지 않습니다. 데이터베이스에 저장하려면 직렬화를 찾아 보는 것이 좋습니다.

0

디자인 관점에서 각 클래스에 대해 별도의 저장을하는 것이 더 유연하다고 생각합니다. 이것은 동일한 속성을 선택하고 DB에 저장하기 전에 필요한 사전 처리를 허용합니다 (즉, 복잡한 객체 자체는 저장할 수 없습니다).

1

일반적으로 나쁜 것으로 또는 적어도 불량한 것으로 이것을 분류합니다. 리플렉션 비용은 여러 단계로 제공됩니다. 가장 비용이 많이 드는 것은 호출입니다 (예 : 호출 방법, 속성/필드 값 가져 오기 또는 설정 등). 리플렉션을 통해 객체를 저장하면 매우 높은 비용이 발생합니다. 속성에 직접적으로 액세스하는 것보다 느린 순서가 있습니다.

반사 비용을 제외하고는 일반적으로 의도적 인 관점에서 나쁜 습관입니다. 모든 속성을 저장하는 중 ... 누군가가 속성을 가진 파생 된 유형을 만들면 어떻게됩니까? 광고에 매핑하지 마라. atabase 테이블 열? 저장 메소드를 가상 또는 추상적으로 설정하고 각 엔티티에 대해 필요에 따라 메소드를 구현/확장해야합니다.

최종 메모에서 ... 이와 같은 엔티티에 직접 저장하는 것은 실제로 발생하기를 기다리는 진정한 유지 관리의 악몽입니다. 관심사와 책임을 하나의 수업으로 혼합 할 때 많은 어려움을 겪고 싶어합니다. 엔티티/비즈니스 객체 POCO (평범한 오래된 clr 객체)를 만들고, 명시적인 데이터 매퍼를 작성하는 것이 훨씬 낫습니다. 이것은 귀하의 우려를 분리하고 각 클래스의 책임을 가능한 적게 줄입니다. 풍부한 셀프 저장 (및 로딩) 엔티티가 편리하지만 대부분 꿈입니다. 실제로, 그들은 당신이 가질 훨씬 더 큰 유지 보수 어려움에 비추어 그들이 제공하는 작은 이익의 가치가 없습니다.

OR 매퍼 (LINQ to SQL, nHibernate, Entity Framework v4 등)를 살펴 보는 것이 좋습니다.) OR 매퍼는 엔티티를로드, 저장 또는 삭제해야 할 때 자동으로 SQL을 생성합니다. OR 매퍼를 사용하지 않을 때 상당한 양의 추가 코딩이 필요 없으며 훨씬 더 적응하기 쉬운 코드 기반을 지원할 수 있습니다.

관련 문제