Creating an Interface to the Data – PriceMatcher

Last time I created an XML structure to store data needed for PriceMatcher. I also created a C# class structure that will serialize to the desired XML. What’s next? How am I going to access the data? The C# data structure is completely public. This creates both problems and opportunities. If I’m not going to be the only person to ever touch the code, how do I ensure that the openness of the structure is not abused? Since it is open, anyone could come along and just read or write data to any area of the structure they want. All of a sudden, instead of a tightly controlled data structure, I’ve instead made a series of nested public variables. That wasn’t my intention at all.

How am I going to limit access to the data structure?

There are more possibilities here than I can think of, but I’m going to consider three. The first is a wrapper class. This provides an interface to the data while keeping data and logic completely separate. When it comes to separation of concerns, this is a pretty good choice. It might look something like this:

public class PricingDataAccess
    private PricingData _dataModel;

    public PricingDataAccess()
        _dataModel = new PricingData();

    public void AddPrice(DateTime priceDate, string productName, double price)
        _dataModel.Prices.Add(new Price()
                Date = priceDate,
                Product = productName,
                Cost = price

Other methods would also be required, such as a way to retrieve the data, but I think this accurately represents the idea. When using the data structure, instead of instantiating an object of the PricingData class, instead I’d instantiate an object of PricingDataAccessor. All of a sudden I can no longer access the data structure directly. This also allows additional benefits such as allowing me to change the data structure in the future without needed to change any reports that implement PricingDataAccessor. I just need to update the accessor class and I’m good to go.

But, there are drawbacks too. This is going to create additional classes and it will create a need to keep open the data structure and the accessor at the same time while performing maintenance since they are tightly coupled. This may not be worth it in the long run, and for me it’s not worth it at this time.

What other options are there?

This logic could be placed directly into the PricingData class. Then, I can continue to use the logic to interact with the data structure. It also provides the added bonus of allowing me to access the data structure when I need it. But, doesn’t this leave me in the same position I was in originally? The data structure is still completely open and accessible. The logic can be used, but there’s nothing preventing it from being ignored.

Here’s a third choice, and the choice that I feel is correct at this time: create a public interface.

public interface IPricingData
    void AddPrice(DateTime priceDate, string productName, double price);

I will also update PricingData to implement IPricingData. Then, instead of instantiating an object of type PricingData, I’ll use IPricingData like so:

IPricingData pricingData = new PricingData();

Now I am limited to how I can interact with the data structure by the interface defined in IPricingData. This both locks down the data structure and prevents creating additional unnecessary classes. Best of all, it may be easier to create base classes with the interface, and still allows the data structure itself to be easily changed and prevents coupling. This could be combined with a factory to loosen the coupling further.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s