Data Access Layer Question RRS feed

  • Question

  • I have a WinForms application that I am developing that I want to fix the Data Access Layer but do not know how to proceed. My application is a desktop application that uses a binary file to persist the application data in a similar fashion as Microsoft PowerPoint.

    I have a class called "ApplicationData". This class contains fields and properties for each of the objects that my application uses. For each data object in ApplicationData I expose a property that allows other classes to access the objects they need. I also Serialize the ApplicationData, and all other class objects in it, using ISerializable to a single binary file. All objects inherit from Iserializable. I pass ApplicationData to all class constructors of objects and services that need it from the mainForm.

    As my application has grown this architecture may not be the best. Is there a better way to do this?

    The ApplicationData class is getting large as I add new features. Also, I would like to have lists of the same type of object in the applicationData class and I would want to get the specific object by using a tag or ID. I know I can use a dictionary object and probably Linq to object. If I had a single object say ObjectA and a Dictionary<ObjectA> objects. I guess I would use a repository. How do I do this for all the different objects in ApplicationData. How do I create a context from either the persistent binary file or the ApplicationData class that can be passed to different repository classes? Will the repository class be responsible for saving and reading data from the binary file?

    Tuesday, June 26, 2012 6:38 PM

All replies

  • When software architects start talking about layers what they really mean is this: can you change one part of the application without breaking the rest of the application?

    So, in your situation, is there any other class or component that relies on the fact that your data is being saved to a flat file, or is it just ApplicationData?  If every component references ApplicationData and only uses its methods and properties, then, in theory, you should be able to write a new version of ApplicationData that persists to a database, or several files, instead of one file.  Right?

    That's really all there is to a data layer.  That you can change the part of the program that interfaces with persistent data without changing anything else.

    So, the data layer should be responsible for persisting data to some store and retrieving it from that store.  In 3-tier architecture, you put another component in between the UI and the data layer whose job is to translate the raw data that comes in and out of the data layer to and from "business objects" - e..g, the data layer would return some bytes, and the business layer would turn those bytes into some object that you can use in your UI layer.  Business objects tend also to have other functions like data validation so that you never put corrupt data into your data store.

    Now, as far as your general approach - ISerializable is a pretty bad idea, because it's not a portable data format, even between different versions of the same assembly.  When you use ISerializable objects and use a BinaryWriter to store them into a file, you're storing them in a .NET specific binary format.  When you use BinaryReader it will attempt to deserialize those objects into instances of .NET classes and the types better be exactly the same or you'll get exceptions.

    It is much better to use an XML serialization format.  It is future-proof and platform independent, two incredibly important aspects to any type of persisted data.  There's also a giant ecosystem of tooling around XML.  Suppose for example that you change the data schema in version 2 of your application and you want to support version 1.0 files.  Good luck with that with ISerializable.   With a simple XSL transform you can port version 1.0 to version 2.0 files. 

    .NET supports two incredibly easy-to-use XML serialization techniques: XmlSerializer and DataContractSerializer.  The former is better if you want human-readable XML and fine control over element and attribute names, and DataContractSerializer is better if you don't.

    Tuesday, June 26, 2012 6:54 PM