2009-12-22 5 views
5

우리는 Entity 프레임 워크 (Silverlight와 RIA 서비스가 정확함)를 사용하여 WPF 응용 프로그램을 작성하고 있습니다. 우리는 모듈을 통해 데이터를 공유함으로써 이익을 얻을 수 있도록 애플리케이션을 통해 공유 ObjectContext를 사용하고 있습니다.Windows/WPF/Silverlight 응용 프로그램의 Entity Framework ObjectContext

문제는 사용자가 작업을하는 동안 열어 본 판매 내역이 ObjectContext에로드되고 응용 프로그램이 끝날 때까지 거기에 머물러있는 경우입니다. 따라서 다른 패턴을 사용해야합니다.

ObjectContexts를 단일 작업 단위로 사용해야 함을 알고 있습니다. 그렇다면 응용 프로그램의 다른 부분에서 무언가가 변경되었고 데이터를 다시로드해야한다는 것을 어떻게 알 수 있습니까?

편집 : Ok, EventAggregator하지만이 경우 다른 모든 부품이 (아마도 대부분 중복) 데이터를 다시로드하게됩니다. 또한 모든 종류의 entite 그룹에 많은 이벤트가 필요할 것입니다.

어떻게 이러한 문제를 해결합니까? 현재 솔루션은 일종의 타협입니다. 전체 appliaction에서 사용하는 핵심 데이터에 공유 ObjectContext를 사용하여 자동으로 공유 및 업데이트 할 수 있습니다. 그리고 많은 양의 데이터에 대해 새로운 별도의 ObjectContext를 사용하십시오. 더 좋은 아이디어?

Garbage collector가 작업을 수행하고 메모리를 해제 할 수 있도록 DataContext에서 엔터티를 "해제"하는 방법이 있습니까?

답변

2

잠깐, WPF입니까, Silverlight입니까? 이 경우, 그들은 매우 다르며 나의 대답은 다를 것입니다.

WPF 솔루션

WPF에서 나는 양식 당 하나의 ObjectContext는을 만들 것입니다. 이렇게하면 컨텍스트는 양식 자체만큼 오래 지속됩니다. 그런 다음 엔티티의 변경 사항을 저장할 때 다른 양식에 데이터를 새로 고쳐야 할 수도 있음을 알릴 수 있도록 이벤트 시스템을 구현해야합니다 (예 : INotifyPropertyChanged). Oren Eini wrote a pretty good article on this architecture using NHibernate in MSDN magazine. 그의 기사에서 아키텍처 개념을 얻을 수 있어야합니다.

실버 라이트 솔루션

이제 실버 라이트는 다르다. Silverlight는 기본적으로 응용 프로그램에서 하나의 양식 만 가질 수 있도록합니다. 예, 폼의 루트 비주얼을 다른 "페이지"로 이동하기 위해 할 수있는 트릭이 있지만 여전히 하나의 양식이며 하나의 Silverlight RIA에서 여러 개의 윈도우를 열 수 없습니다. 이 때문에 Silverlight RIA 인스턴스에 대해 .Net RIA Services ObjectContext를 만들 것입니다. RIA Services는 데이터베이스에 대한 실제 연결이 아니며 웹 서비스에 연결된 캐싱 및 변경 내용 추적 객체 일뿐입니다. 따라서 서버 리소스를 묶어 놓지 않기 때문에이 개체를 더 오랜 시간 동안 존재 상태로 두는 것이 좋습니다. Silverlight RIA가 여러 브라우저 창을 열거 나 Silverlight 개체가 두 개 이상인 경우 Silverlight 인스턴스 당 하나의 ObjectContext가 있어야합니다.

서버에서는 웹 서비스에서 Entity Framework ObjectContext를 사용하며 하나의 요청 기간 동안 만 동안 살아야합니다. 무국적자 일수록 서비스를 더 많이 만들 수 있고, 확장 성이 뛰어나고 성능이 뛰어납니다. EF ObjectContext를 열고 사용하고 최대한 빨리 닫으려고합니다.


편집 :

당신이하고 싶은 모든 후 그냥 context.Detach(entity) 방법을 사용할 수 있습니다, 개체 컨텍스트에서 개체를 분리하는 경우

. example of how to do this on MSDN을 찾을 수 있습니다.

+0

이 응용 프로그램에서는 Silverlight에 대해 설명합니다. Prism/Caliburn을 사용하여보기 (모듈?)마다 단일 ObjectContext를 갖는 것이 문제가 아니라고 생각합니다. 다시 말하지만, 클라이언트에 많은 양의 데이터가로드되면 문제는 무엇입니까? 지금까지 가장 좋은 해결책은 전체 애플리케이션을 통해 사용되는 기본 엔티티에 대한 공유 ObjectContext를 생성하여 자동으로 동기화되도록하는 것이고, 대량의 데이터를로드 할 때 ObjectContexts를 별도로 분리하는 것입니다. 일부 역사적 보고서. – gius

+0

나는 정말로 큰 데이터 블록을 클라이언트에 보내려고하지는 않을 것이다. 대신 서버에서 필터링하고 클라이언트가 그 순간에보고 싶은 결과 만 반환합니다. 인간은 10 만 건의 레코드를 읽을 수 없으므로 많은 레코드를 사람에게 보내지 마십시오. 대신 문제를 검색/필터로 보내고 결과 만 클라이언트에 보냅니다. 보고서를 작성하는 경우 서버에서 집계 요약 데이터를 작성하십시오. 예를 들어, 서버에서 월간 판매량을 계산하고 5000 건의 매출 기록보다 클라이언트에 단일 번호를 전송하는 것이 좋습니다. –

+0

사실입니다. 사용자가 애플리케이션을 사용하는 동안 언제든지 페이지 1, 10, 20이라고 말하면 해당 데이터는 여전히 메모리에 저장됩니다. 반면에 별도의 ObjectContext와 데이터 페이징을 사용하면 메모리에 머물러있는 큰 문제를 해결할 수 있습니다. – gius

1

저장소 패턴을 사용할 수 있습니다. UI와 DAL 간의 추상화 계층.

저장소의 데이터 콜렉션을 정적이며 관찰 가능하도록 만듭니다. 그런 다음 저장소가 그 중 하나를 업데이트 할 때마다 UI 계층이 따라 잡아야합니다. 아이디어.

+0

- 예를 들어,이 그래서 만약 컬렉션이 클라이언트에 머물 것을 조만간 데이터베이스의 1GB 데이터가 클라이언트에로드됩니다. 반면에 이것은 가능한 해결책을 보여줍니다. 아이디어를 가져 주셔서 감사합니다! – gius

0

ObjectContext에서 ObservableCollections를 사용하십시오. NotifyPropertyChange에서 트리거하는 이벤트를 사용하십시오. 보기 모델간에 게시/등록 패턴을 사용하여 변경 사항을 알리고이보기를 사용하여 다른보기를 갱신하십시오.

+1

EF에서 만든 모든 컬렉션은 ObservableCollection이며 엔터티는 NotifyPropertyChanged를 사용합니다. 문제는 appliaction에로드 된 데이터가 메모리에서 해제되지 않기 때문에 전체 응용 프로그램 수명주기 동안 ObjectContext 만 사용할 수 없다는 것입니다. 한편, 단일 액션마다 별도의 ObjectContext를 사용하면 데이터를 새로 고치는 데 문제가 발생합니다. 동일한 데이터가 여러 위치에서 여러 번로드되고 동기화는 모든 데이터 유형에 대한 맞춤 이벤트를 의미합니다. 주요 문제는이 문제에 대한 프레임 워크/패턴이 있습니다. – gius

관련 문제