2009-09-18 4 views
5

MVP 응용 프로그램 (C# Winforms)을 빌드하고 있습니다. 내 초기 버전은 Critique my simple MVP Winforms app ... 이제 복잡성이 커지고 있습니다. 두 개의 별도 텍스트 필드를 두 개의 뷰/발표자 쌍으로 처리하는 코드를 작성했습니다. 간단한 예이지만 동일한 모델을 공유하는 여러 발표자의 세부 정보를 찾아내는 것입니다.MVP에서 모델 공유 Winforms App

내 질문은 모델에 대해 다음과 같습니다 나는 기본적으로 뭔가가 변경된 뷰를 통지하는 모델에 의해 제기 속성 변경 이벤트를 사용하고

  1. . 그것은 좋은 접근입니까? 내가 100 개 또는 1000 개의 속성을 갖는 지점에 도달하면 어떻게 될까요? 그 시점에서 여전히 실용적입니까?

  2.   NoteModel _model = NoteModel.Instance   올바른 방법으로 각 발표자에서 모델을 인스턴스화하고 있습니까? 모든 발표자가 동일한 데이터를 공유하고 있는지 확인하고 싶습니다.

  3. 더 나은 방법이 있다면, 내가 제안을 열려있어

    ....

내 코드는 다음과 같습니다

NoteModel.cs

public class NoteModel : INotifyPropertyChanged 
{ 
    private static NoteModel _instance = null; 

    public static NoteModel Instance 
    { 
     get { return _instance; } 
    } 

    static NoteModel() 
    { 
     _instance = new NoteModel(); 
    } 

    private NoteModel() 
    { 
     Initialize(); 
    } 

    public string Filename { get; set; } 
    public bool IsDirty { get; set; } 
    public readonly string DefaultName = "Untitled.txt"; 

    string _sText; 
    public string TheText 
    { 
     get { return _sText; } 
     set 
     { 
      _sText = value; 
      PropertyHasChanged("TheText"); 
     } 
    } 

    string _sMoreText; 
    public string MoreText 
    { 
     get { return _sMoreText; } 
     set 
     { 
      _sMoreText = value; 
      PropertyHasChanged("MoreText"); 
     } 
    } 

    public void Initialize() 
    { 
     Filename = DefaultName; 
     TheText = String.Empty; 
     MoreText = String.Empty; 
     IsDirty = false; 
    } 

    private void PropertyHasChanged(string sPropName) 
    { 
     IsDirty = true; 

     if (PropertyChanged != null) 
     { 
      PropertyChanged(this, new PropertyChangedEventArgs(sPropName)); 
     } 
    } 

    public event PropertyChangedEventHandler PropertyChanged; 
} 

TextEditorPresenter .cs

public class TextEditorPresenter 
{ 
    ITextEditorView _view; 
    NoteModel _model = NoteModel.Instance; 

    public TextEditorPresenter(ITextEditorView view)//, NoteModel model) 
    { 
     //_model = model; 
     _view = view; 
     _model.PropertyChanged += new PropertyChangedEventHandler(model_PropertyChanged); 
    } 

    void model_PropertyChanged(object sender, PropertyChangedEventArgs e) 
    { 
     if (e.PropertyName == "TheText") 
      _view.TheText = _model.TheText; 
    } 

    public void TextModified() 
    { 
     _model.TheText = _view.TheText; 
    } 

    public void ClearView() 
    { 
     _view.TheText = String.Empty; 
    } 
} 

TextEditor2Presenter.cs는 _model.TheText 대신 _model.MoreText에서 작동한다는 점을 제외하고는 본질적으로 같습니다.

ITextEditorView.cs

public interface ITextEditorView 
{ 
    string TheText { get; set; } 
} 

ITextEditor2View.cs

public interface ITextEditor2View 
{ 
    string MoreText { get; set; } 
} 
+0

+1 큰 질문입니다. 나는 내 마음 속에 똑같은 것을 가지고있다. – Marcel

답변

3
  1. 이 방식이 좋다. 그러나, 당신이 재산의 백 (심지어 수천!)을 가지고 찾고 있다면, 당신은 하나님 클래스 (안티 패턴)을 가지고있을 것 같아요. 100 개의 속성을 가진 좋은 클래스는 많지 않습니다. 대신 모델을 작은 클래스로 나누는 것을 고려하십시오. 또한 각 속성에 대해 별도의 이벤트가 필요하지 않습니다. 모델이 전혀 변경되지 않은 경우 단일 이벤트 (변경 사항을 설명하는 정보가 포함될 수 있음)를 발생시킬 수 있으며 뷰는 해당 이벤트를 처리 할 수 ​​있습니다.
  2. 실제로 적용하고 싶지 않다면 싱글 톤 패턴을 사용하지 않는 것이 좋습니다. 대신 모든 뷰에 대한 생성자를 변경하여 모델의 인스턴스를 가져옵니다.
+0

1. 나는 조금 과장했다. 나는 내가 추적하고 싶은 100 가지를 예상 할 수 있었다. 모델에 대한 내 생각은 캡슐화하고 집계하여 Model.ComplexThing1 (10 개의 속성)과 Model.ComplexThing2 (4 개의 속성) 등이 될 것입니다. 2. 잘 모르겠습니다. 나는 그것을 적용하고 싶다. 내가 어떻게 알아? 모델에 대한 나의 이해는 런타임 중에 저장된 정보의 최종 출처라는 것입니다. 이 경우에는 모델 인스턴스가 하나만 있어야합니다. 맞습니까? –

+0

@ 키스 : "모델 **의 인스턴스가 하나만 있어야합니다 **"와 "** 모델의 인스턴스가 하나 밖에 될 수 없습니다 **"에 차이가 있습니다. 싱글 튼 (small 's'!) 인스턴스는 공장 등에서 하나의 인스턴스를 생성하는 것만으로 자유롭게 사용할 수 있지만, 반드시 **해야 할 때 싱글 톤 (대문자 'S'!) 만 사용하십시오. –

+0

@Johan Gerell : "오직 사용해야 만 할 때 ....":이 상황에서 싱글 톤에 대해 나쁜 점이 있습니까? – Marcel

1

모든 계층 응용 프로그램에서 도메인 모델이 모든 계층을 초월하는 것은 정상입니다.

  1. 따라서, 당신의 발표자가 (의심의 여지가 일종의 컨트롤입니다) 뷰에 참고 인스턴스를 전달했을 후 이상 걸릴에 BindingSource를 통해 데이터 바인딩 할 수 있습니다. 데이터 바인딩을 사용하면 컨트롤은 자동으로 PropertyChanged 이벤트를 수신하고 이에 따라 추가 코드 없이도 업데이트 할 수 있습니다.이벤트 기반 알림은 변경 사항을 염려하는 객체 만 조치를 취할 때 (많은 객체가 불필요하게 조치를 취하는 것과 달리) 모니터링되는 속성의 수와 상관없이 여기에서 적절하게 사용됩니다.

  2. 일반적으로 하위 계층에서 엔티티 인스턴스를 가져옵니다. 예를 들어, Note 인스턴스를 반환하는 서비스를 구현할 수 있습니다. 노트 3에 대한 서비스를 요청할 때마다, 지속 된 데이터에서 생성 된 노트의 동일한 인스턴스를 리턴합니다. 비즈니스 계층에 다른 항목을 더 추가하여 발표자를 보완 할 수 있습니다. WorkItem 또는 Controller를 호출 할 수 있습니다. 모든 발표자는 WorkItem 인스턴스를 참조하여 사용자가 작업 할 Notes의 현재 인스턴스를 가져올 수 있습니다.

나는 복합 응용 프로그램 블록 (또는 CAB)를 스마트 클라이언트 응용 프로그램을 만들려면 다음 패턴을 사용하는 방법의 예를 조사 고려할 것입니다. 모든 디자인 패턴과 OO 원칙이 있으며, 구현 방법은 그만한 가치가 있습니다.

1
  • 질문 1 : INotifyPropertyChanged를 구현하는 것이 나에게 좋은 방법 인 것 같습니다. 아마 당신은 그러나 많은 속성을 몇 개의 클래스로 나눌 것입니다.
  • 질문 2 : 현재 MVP 모델을 여러 발표자와 공유하는 데 싱글 톤 패턴을 사용하고 있습니다. 지금까지는 내 모델의 단 하나의 인스턴스 만이 존재한다는 것을 보장해 주면서 지금까지 행복합니다.
관련 문제