Question

I am using Silverlight with a DDD approach. I have a Person domain object that has properties such as FirstName, LastName, Address, etc. The Person needs to have an Image.

What is the best way to handle this?

I don’t really want to put an Windows.Controls.Image property on the Person object because this it will be coupled to Silverlight/WPF and I might want to use this object with some other technology in the future (ASP, WinForms, the next new thing, etc).

I also need to be able to save and load the image somewhere. Is it best practice to save the image to a database or to a file system? I am currently using nHibernate with Microsoft SQL Server, but I also want to be able to support nHibernate with mySql and possibly some other databases. It is also possible that I may some day want to replace nHibernate with entity framework or some other technology (I am abstracting this out using a repository).

Given this information, how should I handle Images for my Person?

Answer 1

Well, byte[] (or something wrapping a byte[]) is fairly portable… most anything else is going to be implementation specific.

Re database vs file… for the purposes of the client apps (Silverlight, WPF, etc) I would probably expose them via a web page rather than a WCF (etc) call – i.e. some ASP.NET handler (or ASP.NET MVC route) that returns the image via an http call. Then all you actually need in the client is the path to the image (/people/images/12345 or whatever).

For storage – either is usually fine… in SQL Server 2008 you can do both at once with the file-stream type. One of the problems with storing BLOBs in the database is increasing the size, but a few (small) images won’t usually hurt (unless you are using SQL Express and have a capped db size). But using the database has the advantage that a single backup includes everything.

Saying that, though: almost every implementation I’ve done like this has used files.