S
Shannon Lloyd
Hi,
I am writing an app which will permit plugins for various things,
including persistent data storage (ie a database, xml files, whatever;
the app won't care so long as the plugin implements the interface). The
issue is this: when the plugin retrieves data from storage to give to
the app, it is returning data which represents objects from the
application's data model. For example, the application might request the
plugin to retrieve the data for a particular Bicycle object from
storage, and the plugin might retrieve a bunch of data from a database,
eg a unique id (int), a String label, a few other ints, a few other
Strings etc. So the question is this: should the plugin return the "raw"
data (and leave it to the application to create a Bicycle object from
it), or should it create an object of type Bicycle from the raw data and
return that to the application? Returning the object itself *looks*
neater from the point of view of creating the interface for data storage
(ie request a Bicycle by its id, get a Bicycle object back), *but* doing
it this way requires that plugins be built against the application's
data types - a 3rd party plugin developer would be forced to compile
their plugin against the main application, which does not seem like good
design.
Any ideas or suggestions? I was contemplating separating out the
application's data model into its own small jar so that it could be
downloaded separately and linked against by anyone wanting to write a
plugin, which seems like a fair middle ground between requiring the
plugin to be built against the entire application and the application
receiving only "raw" data from the plugin which then has to be converted
into the appropriate object by the application.
Alternatively, is it better to insert an additional layer in between the
main part of the application and the data storage layer to marshall
between the raw data coming back from the data layer and the specific
data types that the application expects?
Thanks for any advice, and apologies for the long-winded post.
Shannon
I am writing an app which will permit plugins for various things,
including persistent data storage (ie a database, xml files, whatever;
the app won't care so long as the plugin implements the interface). The
issue is this: when the plugin retrieves data from storage to give to
the app, it is returning data which represents objects from the
application's data model. For example, the application might request the
plugin to retrieve the data for a particular Bicycle object from
storage, and the plugin might retrieve a bunch of data from a database,
eg a unique id (int), a String label, a few other ints, a few other
Strings etc. So the question is this: should the plugin return the "raw"
data (and leave it to the application to create a Bicycle object from
it), or should it create an object of type Bicycle from the raw data and
return that to the application? Returning the object itself *looks*
neater from the point of view of creating the interface for data storage
(ie request a Bicycle by its id, get a Bicycle object back), *but* doing
it this way requires that plugins be built against the application's
data types - a 3rd party plugin developer would be forced to compile
their plugin against the main application, which does not seem like good
design.
Any ideas or suggestions? I was contemplating separating out the
application's data model into its own small jar so that it could be
downloaded separately and linked against by anyone wanting to write a
plugin, which seems like a fair middle ground between requiring the
plugin to be built against the entire application and the application
receiving only "raw" data from the plugin which then has to be converted
into the appropriate object by the application.
Alternatively, is it better to insert an additional layer in between the
main part of the application and the data storage layer to marshall
between the raw data coming back from the data layer and the specific
data types that the application expects?
Thanks for any advice, and apologies for the long-winded post.
Shannon