Caching large object on the client

Michael Hildner posted on Monday, July 24, 2006

Hi,

I have this applicaton (Windows Forms) that uses some fairly large images. The client's network isn't super-speedy, and it's very noticeable when retrieving a read-only root that contains an image.

I was thinking it's be nice to cache the images somewhere on the client machine. Although I'm not using an application server, I want to make sure I don't do anything that might break that.

What I was thinking was to check for the serialized object on the client's drive in one of the static Get methods. If it exists there, de-serialize it and return it, by-passing the data portal. If it doesn't exist, retrieve using the data portal, and serialize it before giving back to the client.

Anything wrong with this? CSLA-wise or other-wise?

Thanks,

Mike

RockfordLhotka replied on Monday, July 24, 2006

In concept the idea is good, but in practice you can't use the BinaryFormatter for this purpose due to versioning issues. Specifically, if you update your business assembly you won't be able to deserialize data in your cache...

If you can "serialize/deserialize" the object in some other manner then this is an excellent plan. One approach is to write GetData() and SetData() methods on your object, and have the object itself create and consume some type of byte stream (perhaps XML?) in these methods.

Public Class MyBigObject

Private Function GetData() As String
    ' put object's data into an XML stream
    ' return XML as a string
End Function

Private Sub SetData(data As String)
    ' put data into an XML doc
    ' load data from XML doc into object
End Sub

Then your factory method could absolutely use these methods to read/write a local file.

Obviously other variations are quite possible, but the idea is sound and that's what counts.

Michael Hildner replied on Monday, July 24, 2006

Thanks for pointing that out, I didn't realize that serialization included version information. So that wouldn't work for me.

Thinking about it, for this use case, I only need the image property of the object, not the whole object. So I think I may make another, simpler business object, that just contains this one property.

Then I should be able to "serialize/deserialize" - just reading and writing the raw bytes of the image, and I don't think that anything would break when my object/assembly gets updated.

Thanks,

Mike

JonM replied on Monday, July 24, 2006

Mike,

If you are storing the image in a database like SQL Server I would recommend storing it in a seperate table. This could really speed things up when your database grows. Especially if you ever load data from the table without the image (like a read-only list).

Michael Hildner replied on Tuesday, July 25, 2006

JonM,

Thanks for the tip. I am using Sql Server - 2005. The image is not in a different table (yet). And I do load data from the table without the image.

I'll have about 300 records in this table. Most of the images are about 300 KB, but there's a handful that are a meg or two. In addition, there's another image column that's the thumbnail version of the image.

Good candidate to use a seperate table for the images?

Thanks,

Mike