Question

If I have a class with some read-only properties that are populated by a web service call, what is considered the best way to design this?

Is it considered proper for the property getters to make the web service call. It seems that the downside of this is that the getter is doing more than one thing and obscures the expense of the call. I realize that any of the property getters only needs to make the web service call once (by checking for nulls or flag before making the call). But that a single property getter could potentially be setting the private fields for other properties seems to smell to me.

On the other hand if I have have a public method (ie InitWebServiceVals) that calls the web service and updates the private fields I am creating a temporal dependency between the method and the property getters. So the API obscures the fact that you shouldn’t read a property until the “InitWebServiceVals” is called.

Or is there some other method or pattern that addresses this? For example, making the webservice call in the constructor? Or is this generally indicative of a design issue?

I have run into this issue a number of times and I always ended up preferring the second method to the first.

Any thoughts?

Seth

Answer 1

I would throw one other option at you. You could use a factory (either a class or static method) to instance your class. The factory would be responsible for making the web service calls and handing off the property values to the class (either through a parameterized constructor on your class that accepts the values, or by declaring the setters as internal).

This would have the added benefit of decoupling the “how does my class get those values” part from the class itself.

So:

var myClass = MyClass.Create(); // where create is a static
// or
var myClass = MyClassFactory.Create(); // using a separate factory
// or
var myClass = MyClass.CreateFromTestData(value1, value2, value3); // etc