在模型中直接使用業務對象的DependencyProperty是否有意義？

用下面的業務對象：在模型中直接使用業務對象的DependencyProperty是否有意義？

public class ItemsRow : BusinessObject<ItemsRow> 
{ 
    public static readonly DependencyProperty ItemIdProperty = DependencyProperty.Register("ItemId", typeof(int), typeof(ItemsRow)); 
    public static readonly DependencyProperty DescriptionProperty = DependencyProperty.Register("Description", typeof(string), typeof(ItemsRow)); 

    public int ItemId 
    { 
     get { return (int)this.GetValue(ItemIdProperty); } 
     set { this.SetValue(ItemIdProperty, value); } 
    } 

    public string Description 
    { 
     get { return (string)this.GetValue(DescriptionProperty); } 
     set { this.SetValue(DescriptionProperty, value); } 
    } 
}

你會如何在一個模型暴露的屬性，看到的性能如何已的DependencyProperty的？

我在想，如果它將使任何意義，這樣做：

public class ItemModel: DependencyObject 
{ 
    Item _item; 

    public ItemModel(Item item) 
    { 
     _item = item; 
    } 

    public static readonly DependencyProperty DescriptionProperty = Item.DescriptionProperty; 

    public string Description 
    { 
     get { return _item.Description; } 
     set { _item.Description = value; } 
    } 
}

將這項工作作爲預期或將模型一定要有自己的一套的DependencyProperty年代由業務對象的DependencyProperty的支持？或者可以稍微修改以正確工作？

來源

2012-12-26 Brandon Moore

這將不能工作，因爲依賴屬性登記需要知道哪種類型的被定義的屬性;這就是爲什麼你將第三個參數傳遞給註冊方法。到目前爲止，只有這個原因，它將無法正常工作。但從理論上的MVVM設計觀點來看，在模型中有一個與您的業務對象非常相似的獨立對象是您選擇另一層抽象的折衷。您基本上是在購買冗餘，以允許您擁有另一個抽象層，使您可以在不更改模型的情況下交換業務對象。但是，如果您使您的模型對象依賴於您的業務對象實現的細節，那麼您正在擊敗該目的。在這種情況下，我會直接使用「業務對象」作爲模型對象。

來源

2012-12-26 06:58:10 Ameen

我個人認爲這是一個不好的做法，對模特屬性（除非有很好的理由），該模型是不適合的地方 - 如果這發生在一個視圖模型之間則區別和模型趨向變得不存在。 – slugster

@slugster老實說，我認爲我應該調用ItemViewModel。剛剛學習這些東西，以前剛學過MVC。現在我正在回顧一下我正在建模的MVVM示例，我注意到示例項目中甚至沒有Model.cs文件讓我困惑。 –

謝謝Ameen，那是我的一種想法，但只是想仔細檢查是否可以採取任何捷徑。爲了迴應你答案的最後一句話，一個典型的模型（或ViewModel ...你可以從上面的評論中看到，我現在對此有點困惑）會引用多個業務對象。如果模型只引用單個業務對象，那麼我可能會直接使用業務對象。 –

在模型中直接使用業務對象的DependencyProperty是否有意義？

回答

相關問題