對象的屬性什麼時候可用？

前言：這是一個很長的問題，如果你不想閱讀和理解我爲什麼問它，請留下評論「爲什麼不簡單地測試代碼？」對象的屬性什麼時候可用？

我有一個對象模型，它看起來有點像這樣：

public class MyObjectModel 
{ 
    public byte TypeOfNestedObject { get; set; } 
    public string NestedObjectInJson { get; set; } 

    public NestedObjectModel1 { get; set; } 
    public NestedObjectModel2 { get; set; } 
    public NestedObjectModel3 { get; set; } 

    public MyObjectModel() 
    { 
     NestedObjectModel1 = null; 
     NestedObjectModel2 = null; 
     NestedObjectModel3 = null; 
    } 

    public void DeserializeJsonString() 
    { 
      if (TypeOfNestedObject == 1) { 

       NestedObjectModel1 = "deserialize NestedObjectInJson 
            into NestedObjectModel1"; 
      } 

      if (TypeOfNestedObject == 2) { 

       NestedObjectModel2 = "deserialize NestedObjectInJson 
            into NestedObjectModel2"; 
      } 

      if (TypeOfNestedObject == 3) { NestedObjectModel3 ... } 
    } 
}

基本上，對象是由三個嵌套的對象（NestedObjectModel1，NestedObjectModel2和NestedObjectModel3）的。但是，在任何給定的時間，只有其中一個實際使用。在數據庫中，我存儲用於重新創建此對象的字段，其中一個數據庫字段是包含特定實例的三個嵌套對象之一的json字符串。

我的查詢看起來有點像這樣：

var TheObjectModel = from t in MyDC.Table 
        ..... 
        select new MyObjectModel() 
        { 
         TypeOfNestedObject = t.TypeOfNestedObject, 

         NestedObjectInJson = t.NestedObjectInJson 
        };

我使用屬性TypeOfNestedObject知道哪些嵌套對象的MyObjectModel具有特定實例。 目前，查詢執行後，我運行一個方法，讀取TypeOfNestedObject並將字符串NestedObjectInJson反序列化爲適當的類型，並將反序列化的對象添加爲相應的嵌套對象。

現在我想，這樣當該屬性設置查詢運行時，對象會自動反序列化的字符串到合適的類型，以自定義的setter添加到NestedObjectInJson。但是，爲了達到這個目的，該對象還必須正確設置屬性TypeOfNestedObject。我想寫的setter這樣的：

public NestedObjectInJson 
{ 
    set { 

     if (this.TypeOfNestedObject == 1) { 

      NestedObjectModel1 = "deserialize NestedObjectInJson 
            into NestedObjectModel1 "; 
     } 
    } 
}

如果我寫這樣的二傳手，是TypeOfNestedObject必須提供當時的setter運行屬性。如果您注意到，在查詢中，我在加載NestedObjectInJson之前加載了TypeOfNestedObject。

所以現在的問題是：如果我決定刪除調用DeserializeJsonString和創建這個定製的setter，會因爲在查詢它的NestedObjectInJson之前設置或者是查詢所書面作出命令財產TypeOfNestedObject可用該物業的可用性TypeOfNestedObject難以預測？

來源

2013-02-12 frenchie

這將工作，訂單是可預測的。

但是，我會建議反對這樣的事情。乾淨的方法是提供一個構造函數，它接受類型和JSON並執行反序列化。
用這種方法你可以避免你現在擁有的temporal coupling。

來源

2013-02-12 14:54:47

感謝您對時間耦合的建議！我將保留我的代碼，並在查詢運行後在業務層中運行DeserializeJsonString（）。 – frenchie 2013-02-12 15:04:30

對象的屬性什麼時候可用？

回答

相關問題