Files in domain model

Question

What are the best practices for dealing with binaries in domain model? I frequently must associate images and other files with business objects and the simple byte[] is not adequate even for the simplest of cases.

The files:

• Does not have a fixed size and can be quite large thus:
  • Have to be streamed or buffered, preferably in asynchronous manner;
  • Must be cached both on server and client to avoid redundant transfer;
  • On unreliable connections the data transfer can be easily interrupted and has to be resumed - therefore the transfer could start not from the beginning of file but from arbitrary position.
• Are handled differently than the rest of the data:
  • In web applications are not part of the page content but are downloaded by browser separately;
  • Might be a black box that is handled by third-party software;
  • For performance reasons might not even be stored in the database.

How do we go about expressing such files in domain model (or more specifically, in model classes)? If the rest of the model is transferred via DTOs and WCF web services and persisted with NHibernate in the database, but the files not necessarily so, how to make the file handling transparent, part of the overall transaction where applicable yet support all that is necessary for them to be consumed not only in web applications, but also in ordinary desktop applications.

For WPF and ASP.NET the file object must expose some form of Url property that can be data-bound to WPF controls or used in IMG or HTML tags. Uploading a file is a lot more complicated. Preferably, proper presentation and content practices such as MVVM must be maintained there.

I am really lost here as I am not satisfied with any of my previous solutions. What would you advice?

Answer 1

You have to be careful not to try and shoehorn too much functionality into a single class here, your wording sounds a bit like you want a single "File" object that will do everything, this is not a good idea.

You will need to have a concept of a File representation that can be passed around everywhere as you have identified - but this needs to be little more than an identifier and possibly a name - it is then up to individual components to decide how they treat this, for example the HTML page may use a File json object and infer that jsFile.Id needs to be retrieved using ftp://xxx/uploads/{id} or something, while in order to display additional associated information a WCF service might receive the file id and look up info in a database.

It probably makes sense to have a FileAttributesDTO class or some such just to distinguish it from when you are dealing with the physical file. You need to consider seperation of concerns and nail down as many use cases as you can before you proceed really. For example will you really need additional information or would a simple wrapper around an FTP service get you all you need.