Jak wyłączyć niektóre seriale publiczne z serializacji w JsonResult?

Question

Mam niestandardowy viewmodel, który serializowany przy użyciu JsonResult. ViewModel ma pewne właściwości, które muszą być publiczne, ale jednocześnie te właściwości nie powinny być widoczne w wynikowym wyjściu Json.

Próbowałem już użyć atrybutu [NonSerialized], ale to nie miało żadnego efektu.

Czy istnieje prosty sposób na zrobienie tego? Czy musiałbym zakodować własny typ wyniku (w takim przypadku prawdopodobnie nie będę się tym przejmował)?

Answer 1

Możesz umieścić atrybut [ScriptIgnore] na elementach, które nie powinny być serializowane. Zobacz przykład ScriptIgnoreAttribute Class in MSDN.

Answer 2

Niezupełnie odpowiedź szukasz, ale można oszukać Json() stosując następujący kod i anonimowych klas:

MyModel model = ...; 
return Json(new MyModel {model.Prop1, model.Prop2}); 

Answer 3

Można utworzyć klasy otoki, który udostępnia tylko te właściwości, które mają w JsonResult. W poniższym przykładzie krowa ma 2 właściwości - "Noga" i "Moo". Załóżmy, że chcesz tylko wystawiać "Nogi" jako własność. Następnie

Dim cis jak CowWrapper = Nowa CowWrapper (C)

powróci klasę opakowaniu, które tylko odsłania "leg". Jest to również przydatne w przypadku obiektów takich jak DataGridView, jeśli chcesz wyświetlić tylko niektóre podzestawy właściwości.

Klasa publiczna Krowa

Public ReadOnly Property Noga() As String

get 

     return "leg" 

    end get 

koniec Property

Public ReadOnly Property Moo() As String

get 

     return "moo" 

    end get 

koniec Property

klasa koniec

Klasa publiczna CowWrapper

Private m_cow as Cow = Nothing 

Public Sub New(ByVal cow as Cow) 

    m_cow = cow 

end Sub 


    m_cow = cow 

Public ReadOnly Property Noga() As String

get 

     return m_cow.Leg() 

    end get 

koniec Property

koniec klasy

Answer 4

rozszerzyć klasę JavaScriptConverter do nie zawierają prope rty z NonSerializedAttribute. Następnie możesz utworzyć niestandardową ActionResult, która używa Twojego JavaScriptConverter do serializacji obiektu.

To tworzy solidną i sprawdzalną klasę bez konieczności (ponownego) generowania klas opakowania lub korzystania z anonimowych obiektów.

Answer 5

Spójrz na JSON.NET od James Newton-King. Zrobi to, czego szukasz.

Answer 6

Wystarczy utworzyć interfejs, aby powrócić zamiast klasy.

public interface IMyViewModel { 
    string MyPublicProperty { get; set; } 
} 

Następnie należy utworzyć klasę, która dziedziczy jest przez urządzenie

public class MyViewModel : IMyViewModel { 
    public string MyPublicProperty { get; set; } 
    public string MyNotSoPublicProperty { get; set; } 
} 

i powrócić do interfejsu, a nie klasy, w akcji kontrolera

public JsonResult MyJson(){ 
    IMyViewModel model = new MyViewModel(); 
    return Json(model); 
} 

i otrzymaną JSON będzie

{ 
    'MyPublicProperty': '' 
} 

Jednym z wyzwań w skryptach po stronie klienta jest to, że jeśli zmieniasz swoje zajęcia, nie masz pojęcia, czy niszczysz implementację po stronie klienta, czy też nie. Jeśli używasz typów interfejsu w swoim JSON, rozumiesz, że jeśli zmienisz interfejs, robisz coś, co potencjalnie może zabijać implementację po stronie klienta. A także oszczędza od podwójnego sprawdzania strony klienta na próżno, jeśli zmieniasz coś, co NIE jest w inteface (w związku z tym nie jest serializowane).

Również wiele razy Twoje modele ViewModels mogą zawierać duże kolekcje lub złożone typy, które niekoniecznie muszą być wyprowadzane na kliencie. Może to zająć dużo czasu serializacji lub ujawnienia informacji, które po prostu nie należą do kodu klienta. Używanie interfejsów sprawi, że będzie on bardziej przejrzysty, aby wiedzieć, co jest na wyjściu.

Ponadto użycie atrybutów takich jak [ScriptIgnore] w usłudze ma zastosowanie tylko do określonego scenariusza (szeregowania JavaScript), który zmusza do stawienia czoła dokładnie temu samemu problemowi, na przykład w przypadku późniejszego serializowania do formatu XML. To niepotrzebnie zaśmieciłoby twoje modele widoków tonami atrybutów. Ilu z nich naprawdę chcesz tam? Używanie intefaces ma zastosowanie wszędzie, a żaden moduł viewmodel nie musi być zaśmiecony dodatkowymi atrybutami.