2010-02-17 4 views
4

여기에 일부 데이터 레이어 구축하는 동안과 결국 클래스의 : 나는 데이터로 채 웁니다 때문에 응답을 알고 있어야 요청을해야 할이 순환 종속성이 나쁜 것입니까? 어떤 잠재적 인 문제입니까?

public class DataRequest 
{ 
    public class DataResponse 
    { 
    public DataResponse(DataRequest req) { Request = req; } 

    public DataRequest Request {get; set;} 
    // ... here go some other fields ... 
    } 

    public Response { get; set; } 

    public DataRequest() 
    { 
    Response = new DataResponse(this); 
    } 

    public void Execute() 
    { 
    ... Get some data and fill Response object ... 
    } 

} 

는; 요청에 대해 알고 있어야하므로 응답이 필요합니다. 다른 방법에 대한 응답을 전달할 때 원래 요청에 대한 액세스 권한을 갖고 싶어하기 때문입니다.

메모리 누수 같은이 아키텍처의 잠재적 인 문제점을 보았습니까? 아니면 단순히 잘못된 설계 아이디어입니까?

답변

6

너무 나쁘지는 않지만 요청 및 응답을 모두 표시하는 컨텍스트에 대해서만 알 수있는 "DataContext"(더 나은 단어를 원함)를 만들 수도 있습니다. 응답이 요청할 요청에 대해 질문하는 것입니다.

this.Context.Request.SomeProperty; 

메모리 문제는 아닙니다. .NET은 참조 횟수를 계산하지 않으므로 원형 참조에 대해 걱정할 필요가 없습니다. 모두 도달 할 수없는 경우 다른 개체에서 수집하면 수집됩니다. 문제의 시나리오로 인해 세계가 끝나지는 않습니다.

+0

보다 omore 제어를 제공합니다 요청 및 응답 객체가있는 HttpContext. – tvanfosson

+0

감사합니다. 마크, 생각해 보겠습니다. – Andrey

1

내가 그것을 요청과 응답 특성을 모두 보유하는 매니저 클래스를 만들기 위해 더 나은 생각, 내가 ASP.NET이 유지 훨씬처럼 생각 기본적으로 무엇을의 당신이

public class DataManager 
{ 
    public DataRequest Request {get; set;} 
    public DataResponse Response {get; set;} 


    public void Excute() 
{ 
//do you logic here 
} 

} 
관련 문제