Scenario

[Previous] [Next]

Consider any stateful object system such as the equity trading system example mentioned previously. A StockPortfolio object must contain state, which reflects the value of the portfolio, the stocks it contains, the owner of the portfolio, and so on. The state of the StockPortfolio object must be retainable. For obvious reasons, such as to accommodate system crashes and to allow for efficient use of memory, it is rational to expect a stateful object to rehydrate its state from a data store when reincarnated. If the persistence to a data store resides in the implementation detail of each object, the data store becomes increasingly difficult to manage and maintain as the number of stateful objects in the system increases. Also, the business object developer would be required to have intimate knowledge of the data store. The Repository design pattern is an ideal solution for this type of scenario because it abstracts, in a separate object layer, the data manipulation of the data store that contains the state of a distinct type of object. As a result, the data store and the business objects are loosely coupled, so any constraints directly related to accommodating the data store are removed from the business object implementation. Changing data store technologies also becomes significantly less disruptive. Business objects can remain completely unaffected and oblivious to the change. Business object developers' hands are no longer tied by the data store technology or the learning curve associated with adopting a new data store technology.