The EntitySpaces Community

Share and learn about the EntitySpaces Architecture.
Welcome to The EntitySpaces Community Sign in | Join | Help
in
Home Forums Photos

Serializing a complete (nested) Entity

Last post 12-13-2007, 11:21 AM by Mike.Griffin. 3 replies.
Sort Posts: Previous Next
  •  10-09-2007, 4:50 PM 5739

    Serializing a complete (nested) Entity

    I have read some post of others that asked about this, and I realize that the development progresses pretty fast, so maybe this will not be a problem soon but I wish to simply version(serialize) an completely nested entity object and store it in a database field as a binary object, and later reinflate it at will. Would returning a dataset from an entity query be a possible way to do the same thing now.
    Richard Young
  •  10-09-2007, 8:48 PM 5742 in reply to 5739

    Re: Serializing a complete (nested) Entity

    Our plan is to allow you to serialize all objects downstream (that is from the parent down not upward) in xml, this will not support binary format. However, don't be dismayed, the XML will be far smaller than the binary would be as the binary stores everything, the datatable, rows and so on. The Xml merely stored the property values. This is in the works for this release hopefully.

    EntitySpaces | Twitter | BLOG | Please honor our Software License
  •  12-13-2007, 10:09 AM 7160 in reply to 5742

    Re: Serializing a complete (nested) Entity

    I see this comment alot: "don't be dismayed, the XML will be far smaller than the binary would be as the binary stores everything, the datatable, rows and so on."

    First, is the underlying EntitySpaces object a DataTable, not a simple object? I would not expect there to be any data table with columns for any single instance of any object. Second, are you sure about the size of a binary serialization versus XML?

     Here is a quote from Microst on a DataSet:

    "Fill a DataSet with the results of a query and persist it to a file on disk (see Figure 6). You can wrap the code in Figure 6 in either a Web Form or a Windows Form. Run the sample application and take a look at the size of the files created. Try first with a simple query like this:

     

    SELECT lastname, firstname FROM employees

     

     

    If you're familiar with the Northwind database, you know that this query returns only nine records. Quite surprisingly, in this case the XML DiffGram is about half the size of the binary file! Don't worry, there's nothing wrong in the code or in the underlying technology. To see the difference, run a query that will return a few thousand records, like this one:

     

    SELECT * FROM [order details]

     

     

    Now the binary file is about 10 times smaller than the XML file. With this evidence, look back at the graph in Figure 2. The yellow series shows the performance of the DataSet binary serializer and fortunately increases very slowly as the size of the DataSet grows. The same can't be said for the DataSet XML serializer which reports a sudden upswing and significantly decreased absolute performance as the number of rows exceeds a few thousand."

    I mention this because the common opinion with Soap/Xml serialization is that it is smaller for very small collections (where doesn;t really matter anyway), but monstrously larger for large collections, and much much worse when nested objects are involved. Also, note serialization SPPED: the standard .NET binary serializer is known to be much faster than Xml. Now take into consideration that there are many third-party binary serialzers that majorly outperform the .NET binary serializer. A simple example is on the CodeProject: http://www.codeproject.com/KB/cs/AltSerializer.aspx?df=100&forumid=336232&exp=0&select=1654727&tid=1654727.

    From my experience, alternate binary serializers are always the best serialization alternative. The most important factor is simply the time from request to the time to full response (data displayed on screen) and Binary Serialization is simply much faster than Xml (taking into account over-the-wire transfer speeds - if you throw in a nice compression utiltity, size becomes much less of a factor. However, as oted above Xml?Soap is genrally LARGER, not maller than Binary. Any good third-party binary serializer will have the ability to store/cache type information and will not serialize redunant type information for every record as indicated by the statement.

    Anyway, I am just sharing my opinion that Binary Serialization is the most preferrable to share data between a client and server. Also note: I am very open to looking at any sample/ test cases to indicate that Xml or any other alternative is actually preferrable. To date: the test cases provided to me that indicated Xml were preferable were either like the above case from Microsoft (too few records were used to compare properly), or they did not include nested properties, and/or there was somethig amiss.

     

     

     

     

  •  12-13-2007, 11:21 AM 7164 in reply to 7160

    Re: Serializing a complete (nested) Entity

    Yes, EntitySpaces is built upon ADO.NET and uses a DataTable underneath every object. Believe it or not, this is very fast, in fact, very, very fast as we have the benchmarks against most of our competitors who try to copy the data out using readers into their own classes.

    On this BLOG post you can see what I am talking about regarding Binary being very big (for EntitySpaces anyway), it's the DataTable, DataRows, and DataColumns that make it huge, our xml is tiny, in fact, our WFC xml is very tiny.
     


    EntitySpaces | Twitter | BLOG | Please honor our Software License
View as RSS news feed in XML