ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Fabio Collini" <fcoll...@omniagroup.it>
Subject R: Abator factory extension - best practices
Date Tue, 28 Aug 2007 13:18:56 GMT
Hello Jeff,
 
thank you for your reply. We're glad to hear that the way
you suggest of using Abator is quite similar to what we were
thinking about. The idea of having some factory came
out from the need to generate pojos with properties (get and set) protected.
 
We thought to achieve this with the following steps:
 
1) add a new attribute, visibility, to the xml element "columnoverride"
2) changing the DTD accordingly
3) extend the class ColumnOverride to add the new property
4) extend the AbatorConfigurationParser to handle columnoverride.visibility
property
5) modify the bean generator to obtain bean with proptected getter/setter
 
It's difficult to obtain this because there are explicit costructor
invocation
of the parser and of the ColumnOverride (for example inside the method
AbatorConfigurationParser.parseColumnOverride).
We thought that a factory for the parser and the ColumnOverride object would
solve this problem and make the design
more extendible. What do you think?
 
Another question: is it possible to customize the behavior of the
bean/dao/sqlmap generators
so that you can specify your own comment to be inserted? A setComment
method?
 
Thank you
Bye
  _____  

OmniaSoftware ® s.r.l.
Fabio Collini 
(Analista Programmatore) 
Via Melloni, 29 - 50019 Sesto F.no (FI) 
Tel. 0554200158 
 <mailto:fcollini@omniagroup.it> fcollini@omniagroup.it 
http://www.omniagroup.it/ 
  _____  


AVVISO DI RISERVATEZZA
Il testo e gli eventuali documenti trasmessi contengono informazioni
riservate al destinatario indicato. La seguente e-mail è confidenziale e la
sua riservatezza è tutelata legalmente dalle normative vigenti. La lettura,
copia od altro uso non autorizzato o qualsiasi altra azione derivante dalla
conoscenza di queste informazioni sono rigorosamente vietate. Se si ritiene
di non essere il destinatario di questa mail, o se si è ricevuto questa mail
per errore, si prega di darne immediata comunicazione al mittente e di
provvedere immediatamente alla sua distruzione. Le dichiarazioni contenute
nel presente messaggio, nonché nei suoi eventuali allegati, devono essere
attribuite esclusivamente al mittente e non possono essere considerate come
trasmesse o autorizzate da Omnia Software s.r.l.; le medesime dichiarazioni
non impegnano Omnia Software s.r.l. nei confronti del destinatario o di
terzi. Omnia Software s.r.l. non si assume alcuna responsabilità per
eventuali intercettazioni, modifiche o danneggiamenti del presente messaggio
e-mail.

PRIVACY NOTICE
The information contained in this transmittal, including any attachments
hereto, are confidential and privileged, and intended solely for the
specified addressee(s). This e-mail has a confidential nature which is
protected by the Italian law. Moreover, the recipient(s) may not disclose,
forward, or copy this e-mail or attachments, or any portion thereof, or
permit the use of this information, by anyone not entitled to it, or in a
way that may be damaging to the sender. If you are not the intended
addressee, or if you receive this message by error, please notify the sender
and delete this information from your computer. The statements and opinions
expressed in this e-mail message are those of the author of the message and
do not necessarily represent those of OMNIA SOFTWARE s.r.l. Besides, The
contents of this message shall be understood as neither given nor endorsed
by OMNIA SOFTWARE s.r.l.  OMNIA SOFTWARE s.r.l. does not accept liability
for corruption, interception or amendment, if any, or the consequences
thereof.

 

  _____  

Da: Jeff Butler [mailto:jeffgbutler@gmail.com] 
Inviato: martedì 28 agosto 2007 14.48
A: user-java@ibatis.apache.org
Oggetto: Re: Abator factory extension - best practices


Abator generates an anemic domain model.  For this reason, I don't consider
the Abator generated classes to be "domain" objects.  Rather, I consider
them to be low level transfer objects.  In my use of Abator, I almost always
develop a more rich domain model and then write a simple translation layer
between my rich domain model and the Abator generated objects.  I end up
using the generated inserts, updates, and deletes quite frequently, the
selects less so - because I can usually write a join query that more closely
matches my rich domain model.  This is kind of like the Hibernate usage
pattern where there is a 1-1 mapping between objects and tables, with some
higher level domain model and mapping layer. 
 
Of course, sometimes a "rich" domain object is close enough to a row in a
table that the Abator generated object will suffice with a few
modifications.  In that case, I make heavy use of <columnOverride> to rename
the columns so that the object looks more like a "real" domain object. 
 
I quite often add utility methods to the generated DAOs.  These methods make
use of the generated DAO methods and add more "business rule" value.  For
example, if I want a list of all open orders after a certain date, I can
write a custom DAO method that makes use for the select by example
functionality to find these records. 
 
I work in Eclipse exclusively - so I have no issue with modifying the
classes generated by Abator.  I'll re-run Abator many times during a
development effort and Abator always saves any modifications I've made to
the generated objects.  If you're not using the Eclipse plugin, then I'd
suggest doing a sub-classing strategy and not modifying the generated java
objects. 
 
I'd love to hear how others are using Abator - these are just my
experiences.
 
As for your last question, I'm very open to improving Abator.  I'd be
interested to hear more about your ideas for an extensible factory.
 
Jeff Butler


 
On 8/28/07, Fabio Collini <fcollini@omniagroup.it> wrote: 

Hello everyone,
 
we are developers of a software factory working on a project using iBatis
and the Spring
framework and we have found Abator a wonderful tool that really
speed up the work.
 
We were wondering which was the best way to use Abator and
eventually to extend it. For example: is it best to use Abator
to generate mappings and model class only at the beginning and then
modify them to fit our needs or use Abator to continually keep the mappings
in sync with the database? In this second option how do we avoid to have
an "anemic data model"? We thought about a layer of classes that uses
the abator generated ones. It is the best choice?
 
Another question is: could we have the option to make integrations and
editings
to the source code that could be integrated in the source code repository?
The other
option is: could we ask the Abator developers to add some minor changes to
the source
code, in particolar we feel to need to have an extendible factory able to
generate the
classes contained in the package org.apache.ibatis.abator.internal.db. 
 
Thank you for the good work
bye
 

  _____  

OmniaS oftware ® s.r.l. 
Fabio Collini 
(Analista Programmatore) 
Via Melloni, 29 - 50019 Sesto F.no (FI ) 
Tel. 0554200158 
 <mailto:fcollini@omniagroup.it> fcollini@omniagroup.it 
http://www.omniagroup.it/ 
  _____  


AVVISO DI RISERVATEZZA
Il testo e gli eventuali documenti trasmessi contengono informazioni
riservate al destinatario indicato. La seguente e-mail è confidenziale e la
sua riservatezza è tutelata legalmente dalle normative vigenti. La lettura,
copia od altro uso non autorizzato o qualsiasi altra azione derivante dalla
conoscenza di queste informazioni sono rigorosamente vietate. Se si ritiene
di non essere il destinatario di questa mail, o se si è ricevuto questa mail
per errore, si prega di darne immediata comunicazione al mittente e di
provvedere immediatamente alla sua distruzione. Le dichiarazioni contenute
nel presente messaggio, nonché nei suoi eventuali allegati, devono essere
attribuite esclusivamente al mittente e non possono essere considerate come
trasmesse o autorizzate da Omnia Software s.r.l.; le medesime dichiarazioni
non impegnano Omnia Software s.r.l. nei confronti del destinatario o di
terzi. Omnia Software s.r.l. non si assume alcuna responsabilità per
eventuali intercettazioni, modifiche o danneggiamenti del presente messaggio
e-mail. 

PRIVACY NOTICE
The information contained in this transmittal, including any attachments
hereto, are confidential and privileged, and intended solely for the
specified addressee(s). This e-mail has a confidential nature which is
protected by the Italian law. Moreover, the recipient(s) may not disclose,
forward, or copy this e-mail or attachments, or any portion thereof, or
permit the use of this information, by anyone not entitled to it, or in a
way that may be damaging to the sender. If you are not the intended
addressee, or if you receive this message by error, please notify the sender
and delete this information from your computer. The statements and opinions
expressed in this e-mail message are those of the author of the message and
do not necessarily represent those of OMNIA SOFTWARE s.r.l. Besides, The
contents of this message shall be understood as neither given nor endorsed
by OMNIA SOFTWARE s.r.l.  OMNIA SOFTWARE s.r.l. does not accept liability
for corruption, interception or amendment, if any, or the consequences
thereof. 

 



Mime
View raw message