DataContext 객체를 'ref'매개 변수로 전달할 때의 단점은 무엇입니까?

Question

그래서 내 EF4 프로젝트에서 두 DataContext 파일의 부분 클래스뿐만 아니라 DataContext에 의해 생성 된 Table/Object 몇 가지를 열었습니다. 그러나 "제품"클래스를 부분으로 여는 경우 제품 백업에서 생성 된 DataContext 클래스까지 직접 연결되는 링크가 없습니다 (가능한 한 멀리 말할 수 있음).

public partial class Product 
{ 
    public DataContext GetContext() 
    { 
     return this.DataContext; 
     // FAILS!!! No connection from 'this' to DataContext 
     // makes sense because "Product" isn't REALLY derived from DataContext 
     //...but still, I want this to work! 
    } 
} 

그러나 내부 부분 제품별로

, 나는 반드시 데이터베이스를 직접 조회 할 수 있도록하고 싶습니다, 나는 정말 DataContext에의 한 인스턴스를 초기화하고 내 aspx.cs 페이지에 사용할 수 있도록 좋아 쿼리뿐만 아니라 aspx.cs 페이지에서 호출되는 부분 클래스에서 실행 된 쿼리가 포함됩니다.

내 솔루션 지금까지 데이터베이스 주위에 찌를 필요가있는 부분 클래스의 메서드에 'ref'매개 변수로 DataContext의 인스턴스를 전달하는 것입니다.

public partial class Complaint 
{ 
    public IEnumerable<Person> GetPByRole(InvestigationRole roleEnum, ref DataContext dbase) 
    { 
     var role = dbase.GetRole(roleEnum); 
     return this.PeopleOnInvestigations 
        .Where(x => x.InvestigationRoleID == 1) 
        .Select(x => x.Person); 
    } 
} 

그래서이 연결을 통해 데이터베이스에 액세스해야하는 모든 부분 클래스 메소드로 심판 매개 변수로 내 DataContext에 개체 주위에 전달하는 단점이있다 : 여기 부분 클래스입니까? 단점 중 하나는 ref로 전달되면 이러한 부분 클래스 내에서 "AddObject()"새 엔터티를 추가 할 수 있으며 일단 내 asp.cs 페이지에서 내 SaveChanges 콜백이 수행되면 모든 변경 (aspx 및 부분 클래스 메서드에서) 실행됩니다.

Answer 1

우선, ref 변수를 전달하면 참조를 보유하는 변수를 변경할 수 있습니다. 그러나 GetPByRole 메서드에서 DataContext dbase 참조를 변경하지 않으므로 ref으로 전달하면 쓸모가 없으므로 다른 개발자도 혼동을 일으킬 수 있습니다. 아마도 값 유형과 참조 유형을 오해 할 수도 있습니다. 참조 유형 (예 : DataContext)은 항상 참조로 전달되며 메서드 호출을 통해 객체 자체의 새 복사본을 만들지 않고 단지 참조 사본 (32 비트 또는 64 비트 값)을 전달합니다.

둘째로, 여기서 책임을 혼합하고 있습니다. Product 클래스는 엔티티이지만 모든 종류의 데이터 검색 메소드를 구현 한 것 같습니다. 이것은 곧 큰 혼란이 될 것입니다. 시스템의 모든 수업에 단일 책임을 부여하십시오. Person 클래스의 책임은 개인이됩니다.

즉, 저장소 클래스 (또는 그 주변의 서비스 클래스)에 더 적합합니다. 예를 들어,이 방법을 보유하고있는 PersonRepository을 만듭니다. PersonRepository은 새로운 Person 인스턴스를 반환 할 수 있습니다. 사실 리포지토리는 데이터 소스와 응용 프로그램 간의 인터페이스이어야하며 일반적으로 비즈니스 관련 쿼리 메서드를 구현하지 않습니다. 이렇게하면 엔티티가 데이터 컨텍스트 (Entity Framework를 개발하는 동안 ADO.NET 팀의 매우 신중한 디자인 결정)를 알지 못하게됩니다.