DataModel considerations

Aug 19, 2008 at 9:52 AM
Edited Aug 19, 2008 at 9:55 AM

We have been looking at the StockTraderRI and there the services create the data that is shown in the application by reading from a resource application file. For example, in the News Module the "Resources.News" is parsed from which business objects are created and exposed. This is, of course, ok as an illustration of the Composite WPF framework.

We are considering two scenarios with regards to implementing a "live" DataModel where the data will be loaded from and saved to a XML file:

  1. The data is loaded from the XML file, business objects are created and placed in a DataModel object. The services expose the business objects that are in the DataModel to Modules. The DataModel will then have Load(string filename) and Save(string filename) methods.

  2. The data is loaded from the XML file, business objects are created and placed in their respective services. Here the services are responsible for storing the "live" business objects as well as exposing them to Modules. A separate object is responsible for loading and saving the business objects.

We would like to get some input on pros and cons on the above mentioned scenarios. If someone know of any other solutions please feel free to speak your mind :)


Aug 22, 2008 at 7:38 AM
Edited Aug 22, 2008 at 7:39 AM

The RI is really focused on the UI concerns. Everything else is mocked simply to make the UI function. Now we try to do it in a clean fashion, but are not recommending the way we handle business concerns and such is how you should do it in the real world.

Just out of curiosity, why are you reading "live" data from an xml file, as opposed to a database? Is this coming from a web service of some sort? Or is it some static data?

As far as how the models are accessed, I would recommend the Respository pattern, i.e. you Repository<T> objects for your business objects. From the module perspective, how the models are stored is an implementation detail. They should access the Repository to get what the need. The implementation of the Repository itself would manage reading and writing to the XML.

The advantage of this, is that the application modules are completely decoupled from the data store, and from managing persistance.