Re: [Hibernate] Tom Cellucci's database reverse engineering tool

[Gavin K. <ga...@ap...>]

Theres a couple of considerations:

* When theres a large number of persistent classes, a single mapping
document becomes way to large, unmanageable and virtually impossible to
navigate. ie. the same reason why we don't define all our Java classes in
one big file. Plus, it keeps the mapping right there in the same directory
as the mapped class - easy to find and manage. I have had bad experiences
with things like the monolithic struts-config.xml

* In a team environment, multiple files tends to interact much better with
version control systems (not so much in the case of CVS, but certainly with
envy or any system based on locking).


Gavin


----- Original Message -----
From: "Andrea Aime" <aa...@li...>
To: "Gavin King" <ga...@ap...>; "Daniel Bradby"
<db...@bi...>; <hib...@li...>
Sent: Sunday, November 10, 2002 2:41 AM
Subject: Re: [Hibernate] Tom Cellucci's database reverse engineering tool


> On Friday 08 November 2002 23:48, Gavin King wrote:
> > > Can we move towards the "best practise" of having one mapping per
class
> > > maybe?
> >
> > Yeah, I already requested that (theres a thread in the forum).
> >
>
> But why is a best practice? One file per class requires, say, ten open
editors
> to have a look at the whole mapping (A refers a B class, what is it?...
> we'll, let's open B.hbm.xml) and moreover you have more code to write...
> Frankly I just see disadvantages in having more than a single mapping
file...
> Best regards
> Andrea Aime
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> hibernate-devel mailing list
> hib...@li...
> https://lists.sourceforge.net/lists/listinfo/hibernate-devel