소프트웨어 아키텍처에서 INotifyPropertyChanged 인터페이스를 구현할 위치는 어디입니까?

Question

현재 아키텍처에서 잘 알려진 레이어를 신중하게 구분하는 데 충분한 규모의 프로젝트를 만들고 있습니다.

데이터 액세스 계층 (DAL)의 경우 .NET 엔터티 프레임 워크를 사용하기 만합니다.

비즈니스 계층의 경우 클라이언트를 만들고 UI를 처리 할 수있는 후속 개발자가 사용할 수있는 비즈니스 개체를 정의했습니다.

데모 목적으로 클라이언트 응용 프로그램을 개발해야하므로 목록 대신 ObservableCollection<T>을 사용하는 것이 매우 유용 할 수 있으며 가능한 한 자주 개체가 INotifyPropertyChanged 인터페이스를 구현해야한다는 것을 깨달았습니다. UI가 자동으로 변경 사항을 감지하고 즉시 업데이트를 표시합니다.

그러나 아키텍처 관점에서 볼 때 실제로 올바른 방법인지 궁금합니다. 즉, 기술적으로는입니다. 저는 비즈니스 계층이 UI 디스플레이와 관련이 있어야한다고 생각하지 않습니다. 프로그래머가 사용할 수있는 것을 "알지 못합니다". 그는 예를 들어 계산 목적으로 객체를 사용하기를 원할 것입니다. 그래서 나는 무엇이 일반적인 관행인지 궁금해하고 있었다.

비즈니스 레이어에 이러한 기능을 구현해야합니까? 성능상의 문제는 없습니다. 이러한 모든 기능을 포함하는 다른 레이어에 "decorator"객체를 만들어야합니까?

Answer 1

의견에 Skliwz으로 언급했듯이 정확한 배치 장소는 UI 레이어에 구체적으로 바인딩 된 개체입니다. 당신은 UI 계층에 직접 비즈니스 오브젝트를 결합하고, 당신이 INotifyPropertyChanged 인터페이스가 정말 귀하의 비즈니스 오브젝트에 속하지 않는 것을 발견하면

는, 그것은 당신이 다른 목적으로

을 위해 다른 개체가 있어야 명확한 표시입니다

예를 들어 Model View View Model 패턴을 사용하여보기 모델을 만들 수 있습니다.

그러나 비즈니스 오브젝트가 다른 시스템에 의해 모니터되고 변경된시기에 대한 통지가 필요한 경우, INotifyPropertyChanged 인터페이스가 적합합니다. 그러나, 당신의 특정한 경우에서 같이 소리가 난다, 그렇지 않다.