All,
I have some rather complex objects that need to be viewed at varying
'depths'. In fact, in many ways the entire database contains objects
that are inter-related and I only want to be looking at a subset at any
one time. This is causing me some grief in my module and testing layout.
Let's imagine that I have Foo objects and Bar objects. Each Foo can
belong to one Bar. Each Bar can contain multiple Foos. The Foo object
has a getBar() routine. The Bar object has a getFooList() routine.
If I am looking from the viewpoint of an individual Foo object, I may
wish to get the Bar object that it belongs to without filling up the Bar
object with all the other Foo objects it contains.
We have implemented this using a lazyload design. The Foo will be
created with a skeleton Bar object inside it which it can return on
request. When asked for its Foo list, the Bar object will go and fetch
them from the datasource if required.
To further complicate the issue, we have multiple datasources. Each
object must also know the datasource from which it came so it can go
back to do the lazyload if required.
We have a base interface defined for the Foo and Bar objects that just
define the objects' API. There is a DatasourceAware implementation of
those APIs which contains the code to do the lazyload.
We have also defined a series of DataAccessObject (DAO) APIs which are
used to return instances of the individual objects. Each datasource then
provides a concrete implementation of these DAO APIs which do the actual
work of fetching the data from database, webservice, file etc.
In order to write tests for the LazyLoad code in the
DatasourceAwareImplementation, I need to create a set of MockDAOs. These
will return MockDatasourceAware objects. However, these will be
dependent on the DatasourceAwareImplementation (unless I replicate all
the code). So I end up with a set of code that depends on a mock package
which depends on the original set of code. Since this is circular, maven
bitches about it.
Has anyone else done anything as complex (read: STUPID) as this and can
anyone suggest any sensible, practical solutions?
Later,
Andy
-------------
Yada, yada, yada...
Roslin Institute is a company limited by guarantee, registered in
Scotland (registered number SC157100) and a Scottish Charity (registered
number SC023592). Our registered office is at Roslin, Midlothian, EH25
9PS. VAT registration number 847380013.
The information contained in this e-mail (including any attachments) is
confidential and is intended for the use of the addressee only. The
opinions expressed within this e-mail (including any attachments) are
the opinions of the sender and do not necessarily constitute those of
Roslin Institute (Edinburgh) ("the Institute") unless specifically
stated by a sender who is duly authorised to do so on behalf of the
Institute.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
