Home

Summary

Lazy PI started out as a simple tool for deserializing PI objects. Since then the goals of this project have evolved. In the future, a set of objects will be created to facilitate lazy loading and a more object oriented design. Lazy loading helps limit the number of calls WebAPI to only those objects that are needed.

Object Outline

Objects are designed around the different "controllers" included in the PI WebAPI. For those familiar with the AF SDK, LazyPI should feel familiar. To do this the objects outlined in the paragraphs below have been designed to follow a similar pattern.

For each major object(ex. AFElement, AFEventFrame) a static class will be provided for basic calls(ex. Find, Create) where those properties(ex. ID, path) managed by AF may not be know.

There will also be instance oriented objects that will represent a single object from the AF Database. These object instances will provide the developer with access to referenced objects that are relevant. For example an instance of AFElement will contain a list of its child AFElement. These children should be lazy loaded to limit the queries to only when the object is called.

An interface will be created to house all of the calls relevant to a controller. The calls defined in these interfaces will be exposed through the Static and Dynamic objects. Each Static and Dynamic type will only expose a subset of the methods in the interface.

Naming Convention

Instance Objects - those objects which reference a specific instance will simply use the singular form of the controller it exposes. (ex. AFElement)

Static Objects - those objects which create a general interact for unknown objects will use the plural form of the controller it exposes. (ex. AFElements)

Controller Interface - the interfaces for interacting with a specific controller will use the singular form of the controller it exposes prefixed by an 'I' (ex. IAFElement)

Testing

Two types of unit tests will be created. There will be unit test for testing the general lazy objects, and there will be tests for testing the interface implementations.

Lazy objects will be tested on there ability to provided relevant data about a specific AF data object. Lazy objects should have tests which check the functionality of each child lazy object and also tests for checking that data stays relevant over time. Relevance of the data held in a data object can be rated on its ability to update AF after it receives a change. A stub interface will be created to mimic interactions with the data services.

Interfaces will be tested to insure that all CRUD transactions are operating correctly. These tests will simply create an instance of the interface to be tested and call each of it's methods in a logical order. Testing that illogical interactions fail properly will also be important.