This is the single most valuable optimization tip for 99% of poor-performance cases we’ve seen!
What many developers overlook is that the ‘normal’ entity classes – e.g. IProduct and IInvoice – are essentially proxy classes, in themselves containing no data except a simple reference. This means that every single reading or writing of properties results in a round-trip! For example, reading the Name property of an IProduct object is essentially a wrapper around the SOAP call Product_GetName. This is obviously extremely inefficient when you need to read or write many multiple properties on multiple objects.

Enter data classes:

- All classes have a data class equivalent – for example, the data class equivalent of the IProduct class is the IProductData class
- Data classes expose the exact same properties and methods as their non-data equivalents
- Reading and writing properties on a data object never results in a round-trip
- The price: You must explicitly ‘save’ changes on data objects

Data classes can be used for both reading, creating and updating entities:
- To read a single entity, use GetData()
- To read multiple entities, use GetDataArray()
- To update from a single entity, use UpdateFromData()
- To update from multiple entity, use UpdateFromDataArray()
- To create a single entity, use CreateFromData()
- To create multiple entities, use CreateFromDataArray()

In addition to the huge performance gain, a further advantage of using data classes is that they add a somewhat more transactional level to writing data – since the e-conomic API generally works transactionally on a per-round-trip basis.

There are, however, also a few ‘gotchas’ when using data arrays:
- Whether you’re reading, creating or updating data, you should limit each ‘bulk’ – array – of data to a maximum of 500 or 1,000 entities. Otherwise, you’ll easily run into client-side timeouts.
- Data classes only save you round-trips on simple properties and basic object reference properties. For example, if you read myProductData.ProductGroup.Name, this will result in a round-trip (calling the SOAP method ProductGroup_GetName). For some background and tips for working around this, you can read this blog post.