Whenever I have seen the pattern used (or abused) there is a set of
domain model objects and then a set of dto's used to transfer or
serialize them or whatever.
In GeoServer we explicitly killed any notion of dto's and stick with
just a set of domain model objects. Which are made as simple and java
bean like as possible in order to make serialization as simple as possible.
-Justin
On 3/2/10 9:27 PM, Jody Garnett wrote:
> Um sorry for "dto" - is my understanding wrong? For me a creating a bean in
> order to "serialize directly" is is called a data transfer object.
>
> The idea crops up in punting stuff across the wire; in and out of the
> database etc... I think Java EE hijacked the use and thus is the source of
> scaring you :-(
>
> I also agree that Option 1 is the way to go; if we get stuck on multiple
> interaces or something crazy we can mix in a bit of Option 2.
>
> Cheers,
> Jody
>
>
> On 03/03/2010, at 12:36 PM, Justin Deoliveira wrote:
>
>> ack!! the word "dto" scares me. As far as I know there is no need for dto's
>> here as the intent is to serialize java beans directly. Not transform them
>> to dto's for sending over the wire or whatever...
>>
>> Which I think is what you mean. But nevertheless i see what you are getting
>> at. But I would rather change the minimum than go for an api paradigm shift.
>> So option 1 rephrased as "pull up sueprclass beans" :P
>>
>> -Justin
>>
>> On 3/2/10 8:00 PM, Jody Garnett wrote:
>>> I probably just did not explain very well - in both cases there should
>>> be no api shift for geoserver and no behavior should change at all.
>>>
>>> Option 1 - pull up a superclass DTO. This is probably what we will do
>>> since there is an Eclipse Refactoring support for it and it can be done
>>> smoothly as a result.
>>>
>>> Option 2 - push the DTO into a delegate
>>>
>>> Option 3 - straight up separation
>>>
>>> There is another unstated question here - how to make the Bean/DTO
>>> available? Option 1 can be done with an instanceof check; but you may
>>> wish to return a copy.
>>>
>>>
>>> BEFORE
>>>
>>> class FeatureTypeInfo {
>>> XYZ xyz;
>>> Catalog catalog;
>>>
>>> XYZ getXYZ(){ return xyz; }
>>> Catalog getCatalog(){ return catalog; }
>>> }
>>>
>>> OPTION 1 AFTER PULL UP SUPER CLASS REFACTORING:
>>>
>>> class FeatureTypeInfo extends FeatureTypeMetadata {
>>> Catalog catalog;
>>> Catalog getCatalog(){ return catalog; }
>>> // optional publish metadata
>>> FeatureTypeMetadata toMetadata(){
>>> return new FeatureTypeMetadata( this ); // return a copy for safety
>>> }
>>> }
>>>
>>> class FeatureTypeMetadata {
>>> XYZ xyz;
>>> FeatureTypeMetadata( FeatureTypeMetadata origional ); // copy constructor
>>> XYZ getXYZ(){ return xyz; }
>>> }
>>>
>>> OPTION 2 AFTER DELEGATION (same arrangement just using aggregation
>>> rather then superclass; works better with multiple inheritance of
>>> interface);
>>>
>>> class FeatureTypeInfo extends FeatureTypeMetadata {
>>> Catalog catalog;
>>> FeatureTypeMetadata delegate;
>>> Catalog getCatalog(){ return catalog; }
>>> XYZ getXYZ(){ return delegate.getXYZ(); }
>>> // optional
>>> FeatureTypeMetadata toMetadata(){
>>> return new FeatureTypeMetadata( delegate ); // return a copy for safety
>>> }
>>> }
>>>
>>> class FeatureTypeMetadata {
>>> XYZ xyz;
>>> FeatureTypeMetadata( FeatureTypeMetadata origional ); // copy constructor
>>> XYZ getXYZ(){ return xyz; }
>>> }
>>>
>>> OPTION 3 AFTER STRAIGHT SEPARATION
>>>
>>> class FeatureTypeInfo extends FeatureTypeMetadata {
>>> Catalog catalog;
>>> FeatureTypeMetadata delegate;
>>> Catalog getCatalog(){ return catalog; }
>>> XYZ getXYZ(){ return delegate.getXYZ(); }
>>> // optional
>>> FeatureTypeMetadata toMetadata(){
>>> FeatureTypeMetadata metadata = new FeatureTypeMetadata();
>>> metadata.set( xyz );
>>> return metadata; // externalise metadata content
>>> }
>>> }
>>>
>>> class FeatureTypeMetadata {
>>> XYZ xyz;
>>> void setXYZ( XYZ value ){ xyz = value; }
>>> XYZ getXYZ(){ return xyz; }
>>> }
>>>
>>>
>>>
>>> On 03/03/2010, at 10:45 AM, Justin Deoliveira wrote:
>>>
>>>> Not sure I agree here, or maybe I just don't understand you. The
>>>> beauty of the extension method is that there is no api shift for
>>>> GeoServer. It is a straight refactor and *no* behavior should change
>>>> at all.
>>>>
>>>> I agree that we do walk a thin line providing straight pojos and
>>>> classes that do data access in the same interfaces and classes. But
>>>> something like this is a separate concern as far as i am concerned and
>>>> should occur after the refactor is completed.
>>>>
>>>> -Justin
>>>>
>>>> On 3/2/10 6:28 PM, Jody Garnett wrote:
>>>>> Thought about this a bit more... think it may be "safer" in terms of
>>>>> api shift to use aggregation rather then extension. The problem we
>>>>> had with the previous STRUTS stuff came down to duplicating methods
>>>>> every which way and I am worried about the same path ....
>>>>>
>>>>>
>>>>> class FeatureTypeInfo {
>>>>> FeatureTypeMetadata bean; // wrapped
>>>>> Catalog catalog;
>>>>> ... accessors and delegation
>>>>> }
>>>>>
>>>>> On 02/03/2010, at 7:46 PM, Jody Garnett wrote:
>>>>>
>>>>>> Catching up ... I share justin's frustration on this one (seen the
>>>>>> catalog api too many times!).
>>>>>>
>>>>>> One possible avenue forward would be to pull out a super class;
>>>>>>
>>>>>> FeatureTypeInfo extends FeatureTypeMetadata ....
>>>>>>
>>>>>> That way you are not stuck removing setCatalog / getCatalog and
>>>>>> other methods justin needs to make the catalog go? However I am not
>>>>>> sure that helps you with your need.
>>>>>>
>>>>>> Can you please clarify the purpose; are you really just wanting a
>>>>>> "data transfer object" to send back and forth? ie you would like to
>>>>>> send java beans back and forth between the applications?
>>>>>>
>>>>>> Jody
>>>>>>
>>>>>> On 25/02/2010, at 11:41 PM, Emanuele Tajariol wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I created a GSIP about a refactorization of the catalog beans.
>>>>>>> You can find it at
>>>>>>> http://geoserver.org/display/GEOS/GSIP+45+-+Moving+GeoServer+model+in+a+standalone+module
>>>>>>>
>>>>>>> Here's a little excerpt from the proposal:
>>>>>>> ==============================
>>>>>>> At the moment, when an external app needs to exchange data with a
>>>>>>> GeoServer
>>>>>>> instance (e.g.: via REST or by accessing a DB-based catalog), it has to
>>>>>>> re-define its own set of beans representing Stores, Resources,
>>>>>>> Styles and so
>>>>>>> on.
>>>>>>>
>>>>>>> It could be extremely handy if external applications could use the
>>>>>>> very same
>>>>>>> *Info beans used by GeoServer (both interfaces and related
>>>>>>> implementations).
>>>>>>>
>>>>>>> In the present architecture this cannot be accomplished without
>>>>>>> importing in
>>>>>>> the external app all the catalog logic, that is useless outside a
>>>>>>> complete
>>>>>>> GeoServer instance.
>>>>>>>
>>>>>>> All in all, this refactoring will make clear the boundaries of metadata
>>>>>>> objects, making the creation of modules for
>>>>>>> marshalling/umarshalling them
>>>>>>> much simpler.
>>>>>>> ==============================
>>>>>>>
>>>>>>> Ciao,
>>>>>>> Emanuele
>>>>>>>
>>>>>>>
>>>>>>> -------------------------------------------------------
>>>>>>> Ing. Emanuele Tajariol
>>>>>>>
>>>>>>> GeoSolutions S.A.S.
>>>>>>> Via Carignoni 51
>>>>>>> 55041 Camaiore (LU)
>>>>>>> Italy
>>>>>>>
>>>>>>> phone: +39 0584983027
>>>>>>> fax: +39 0584983027
>>>>>>>
>>>>>>> http://www.geo-solutions.it
>>>>>>> http://geo-solutions.blogspot.com
>>>>>>> -------------------------------------------------------
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Download Intel® Parallel Studio Eval
>>>>>>> Try the new software tools for yourself. Speed compiling, find bugs
>>>>>>> proactively, and fine-tune applications for parallel performance.
>>>>>>> See why Intel Parallel Studio got high marks during beta.
>>>>>>> http://p.sf.net/sfu/intel-sw-dev
>>>>>>> _______________________________________________
>>>>>>> Geoserver-devel mailing list
>>>>>>> Geoserver-devel@lists.sourceforge.net
>>>>>>> <mailto:Geoserver-devel@lists.sourceforge.net>
>>>>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Justin Deoliveira
>>>> OpenGeo - http://opengeo.org
>>>> Enterprise support for open source geospatial.
>>>
>>
>>
>> --
>> Justin Deoliveira
>> OpenGeo - http://opengeo.org
>> Enterprise support for open source geospatial.
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
