I'm switching from InProc session to SQL server session. Currently, my session object looks like this:
public class UserSession{
public string TheStrings {get;set;}
public int TheInts {get;set;}
public List<MyObjectModel> ListOfObjects {get;set;}
}
It basically holds strings, ints and several lists of objects. What I do is store this object in the session and then when I need to access the session, I can write UserSession.TheStrings.
Now that I'm cconverting this to SQL session, serialization comes in play. Do I need to add the [serializable] attribute only to the entire class or do I also need to add it to the class definition of all the MyObjectModels as well?
Thanks.
I am pretty sure it will serialize by default as long as everything in your objects are simple types.
SerializableAttribute Class
Apply the SerializableAttribute attribute to a type to indicate that
instances of this type can be serialized. The common language runtime
throws SerializationException if any type in the graph of objects
being serialized does not have the SerializableAttribute attribute
applied.
Apply the SerializableAttribute attribute even if the class also
implements the ISerializable interface to control the serialization
process.
All the public and private fields in a type that are marked by the
SerializableAttribute are serialized by default, unless the type
implements the ISerializable interface to override the serialization
process. The default serialization process excludes fields that are
marked with the NonSerializedAttribute attribute. If a field of a
serializable type contains a pointer, a handle, or some other data
structure that is specific to a particular environment, and cannot be
meaningfully reconstituted in a different environment, then you might
want to apply the NonSerializedAttribute attribute to that field.
Related
I have an ASP.NET application which uses InProc session state mode. I have a class marked as serializable:
namespace MyNamespace
{
[Serializable]
public class MyClass
{
public System.Web.Mvc.SelectList myList { get; set; }
}
}
...Now I have a doubt: When assigning the property value within the serialized class to the session object like below:
Session["MyList"] = InstaceOfMyClass.myList;
... is myList property automatically serialized once inserted to Session["MyList"] object?
In case it is not serialized, how can I serialize it on inserting to Session["MyList"] object? by indicate property with serializable attribute?
If you are talking about in-process only, serialisation doesn't happen, the item is stored as a normal live reference to a .NET object, no serialisation happens.
If your session state is external (e.g. database) then obviously they need to be serialised at that point.
With regards to your specific point, there is no difference between what you are doing and creating the SelectList object manually and passing that into the session.
If I were you, I would strongly recommend that you do not store objects like this in the session, try to keep it to classes that you control (and can mark as Serializable), because if you do need to switch to out-of-process storage, you won't need to re-engineer your code.
Serialization and passing a model (and some extra data) from the controller to the view (as indicated by the System.Web.Mvc.SelectList) are two very different things.
Serialization has to do with turning an object into a string (or binary array) and Deserialization back from a string (or binary array) to an object.
The model passed back and forth on MVC is what the view should render. You're probably looking for a single property in that model (say countryID) to be displayed in a drop down list (or an html <select> or more generally a combo box). This bundle of wrapping data (say - the list of countries - Id and name pairs) should be passed on via a ViewBag or ViewData.
A SelectList should NOT be done on session as storing it is a big waste of memory. It will just linger there in memory long after the user has received his HttpResponse. A select list is just a list of options in the combo box, and as such it is not serializable (although it's content might be). You should really make the distinction between "the data inhabiting the combo box" (thin object) and "the combo box itself" (fat object). In this example - between the countries (which are an IEnumerable), and the UI element. Serializing a UI element doesn't make sense, and should always be avoided.
If I have [Serializable] attribute on a class then it causes the resulting serialised Json string to include backing members created by the framework.
For example I get below for my Id field:
<Id>k__BackingField=20001
I could find many resources on SOF and elsewhere to get around this problem but I couldn't find why Json serializer is behaving differently when it sees [Serializable] attribute.
If the Jason serializer doesn't serialise members and only serialise properties then why does it behave differently when a class is decorated with [Serializable] attribute?
Please note I'm not looking for a way to fix this issue as I have already found that. I would like to know why Newtonsoft.Jsonserialiser behaves differently here.
In case someone wants to find the reason in the future, following explains how objects are serialised by Json.Net:
Breakdown of Type Serialization > Objects
By default a type's properties are serialized in opt-out mode. What
that means is that all public fields and properties with getters are
automatically serialized to JSON, and fields and properties that
shouldn't be serialized are opted-out by placing JsonIgnoreAttribute
on them. To serialize private members, the JsonPropertyAttribute can
be placed on private fields and properties.
Types can also be serialized using opt-in mode. Only properties and
fields that have a JsonPropertyAttribute or DataMemberAttribute on
them will be serialized. Opt-in mode for an object is specified by
placing the JsonObjectAttribute or DataContractAttribute on the type.
Finally, types can be serialized using a fields mode. All fields, both
public and private, are serialized and properties are ignored. This
can be specified by setting MemberSerialization.Fields on a type with
the JsonObjectAttribute or by using the .NET SerializableAttribute and
setting IgnoreSerializableAttribute on DefaultContractResolver to
false.
A friend asked me this and not sure how to understand. Prolly a simple answer.
He has the following
Public Class TestClass
Public Sub Setup()
MsgBox ("Hello")
End Sub
End Class
Based on that example, what type of member is Setup, in relation to the TestClass class?
I think it it might be an instance member. Because a class is just a collection of instances (methods, properties, etc) within the class.
Correct?
This would be an instance method as opposed to a class method (static methods).
When a field, method, property, event, indexer, constructor, or destructor declaration does not include a static modifier, it declares an instance member.
More information here.
Initially my answer said that a member is the same as a field. According to the MSDN link above this was not entirely correct so I adjusted it. You'll also notice that they use the term static member instead of instance member.
Terminology is a very tricky subject and you'll notice people use many different descriptions for the same subject. This is further amplified when you take other languages in consideration and the terminology there.
It is an instance method, but not because a class is a collection of instances.
It is an instance method because TestClass is not shared (static), and must be instantiated. That is, there must be a instance of TestClass available to use its method Setup(). Conversely, with a Shared class, you do not need an instance of TestClass to use Setup(), it would be a Shared method and not an instance method.
That is academic, however, since VB does not support static classes (Shared Classes), but does support shared methods, the effective difference is that declaring Setup() as Public makes it an instance method, or declaring it as Shared would make it a static method.
I have a class that inherits from JsonConverter:
JsonDataBagCreationConverter<T> : JsonConverter where T : IDataBag
I have a class Company that implements IDataBag
When I deserialize a single property of Company JsonDataBagCreationConverter has its ReadJson method invoked as I expect.
When I deserialize an array of Company, JsonDataBagCreationConverter has its ReadJson method invoked as I expect.
It also works for generic lists of Company.
But for certain containers of Company json.net will not recognize that the contents of the list is of type Company. So JsonDataBagCreationConverter is not used when I deserialize.
ie containers of type
System.Collections.DictionaryEntry,
System.Collections.ArrayList,
System.Collections.Hashtable,
System.Collections.SortedList
that stores Company objects.
I know that these containers are non-generic.
Is it possible to make the (de-)serializer look at the contents of these containers and use the JsonDataBagCreationConverter when the contents is Idatabag (ie a company)?
Best regards
Jan
Remove the where T : IDataBag from the converter and override CanConvert and write your logic to check your type there and accordly return true or false.
Using ObjectDB
[ObjectDB 2.4.1] javax.jdo.JDOUserException
Attempt to store an instance of a non persistable type com.A
#PersistenceCapable
public abstract class B
{
...
#Embedded
protected com.A a = new A();
}
Unfortunately we have been using class A from a library for many years and don't have source available anymore and I cannot put PersistenceCapable annotation on com.A.java. What can I do?
Edit
I think the answer is to add package.jdo for class A. But I still don't understand why is JDO making me either add annotation or make an entry in .jdo file for every class that i want to persist. I wish this could somehow be driven by Serializable interface.
Serialization in ObjectDB is disabled by default, in order to encourage using JPA/JDO persistable types (entity classes, persistence capable classes, embeddable classes), which are more efficient, whenever possible.
However, when serialization is required you can enable it, as explained in the ObjectDB manual.
and then you should be able to store instances of serializable instances in your ObjectDB database.