ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Butler" <jeffgbut...@gmail.com>
Subject Re: Abator factory extension - best practices
Date Tue, 28 Aug 2007 12:48:10 GMT
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
>
>  ------------------------------
>  *Omnia**S**oftware** (r)* s.r.l.
> *Fabio Collini *
> (Analista Programmatore)
> Via Melloni, 29 - 50019 Sesto F.no (FI)
> Tel. 0554200158
> 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