Jeff, I understand. I realize its beyond the intended scope of Abator. Maybe this is geared more toward helping with initial design, I don't know.
The XSD idea... been doing some research on replication and related things we are working on. Seems like a lot of tools are beginning to be geared around the XSD model. And so I was just extrapolating, I would love to have a single model or models (XSD) from wich I could generate Domain Objects, DAOs, DDL, and XML Marshalling stuff, etc. For DAO stuff we have been using Spring/JDBC but recently really began using iBatis - which we just think is the coolest. We don't use the DAO aspects of iBatis; just the mapping. Anyway, if there was a way to code generate a big chunck of the stuff one needs from a well formed model it would be really cool. And, I think, good for iBatis. Thanks for the feedback. Jeff Butler-2 wrote: > > I'm glad you like Abator. > > I've thought about relationships too. I do think that the relationships > should be defined in the Abator configuration rather than reading the > foreign keys. > > I've been using Abator on projects since before I released it a year ago. > In that time I've developed some usage patterns that, I think, make the > best > use of the generated objects (I'll try to get something more substantive > written about that sometime). The bottom line for me is that the Abator > generated objects give a huge jump start to a project, but they don't do > the > whole job. > > I typically use the Abator objects for all inserts, updates, deletes and > many selects. I reuse the deleteByExample and selectByExample methods all > over the place. But I also write custom selects to fill out my "real" > domain objects (for the most part, I don't consider the Abator objects to > be > real domain objects). These custom selects will often use joins and the > iBATIS groupBy support and other features to better match my real domain > objects. All of this is well hidden behind a service layer that only > deals > with the real domain objects. > > With this usage pattern, Abator supporting relationships is a much lower > priority for me - because I don't consider the Abator objects to be real > domain objects, and I probably wouldn't want my domain objects to be > constrained to looking like DB tables. The databases I work with are > rarely > designed like an object model (because DBAs are not OO guys). This is > also > why iBATIS is such a good fit for many of my projects. If the DB "looked > right" to me in the OO sense, then I'd probably go with Hibernate. > > That's a long winded answer to say that I think doing relationships would > be > interesting technically, but it is a lower priority for me because I'm not > sure how useful the generated objects would be in a real life iBATIS > project > - after all, we're not trying to reinvent Hibernate :) > > Could you elaborate on your XSD idea? I'm not sure exactly what you mean. > > Thanks for the feedback! > Jeff Butler > > > > > > > On 11/29/06, Joe Weder <[EMAIL PROTECTED]> wrote: >> >> >> Took a look at Abator... really nice. >> >> Ideally, for me, I think it would be awesome to generate mappings to >> first >> class business models instead of table classes. By that I mean complex >> models with object graphs. It would entail doing joins etc. I see iBATIS >> can >> handle this but ABATOR does not honor this when it extracts the foreign >> key >> relationships. >> >> I wish for ABATOR to be driven be maybe an XSD? DDL can be extracted from >> an >> XSD. There are ways to generate other artifacts from XSD. Business Object >> interfaces and implementations and marshalling code for example. >> >> Anyone else think this would offer huge potential for iBATIS? >> -- >> View this message in context: >> http://www.nabble.com/Abator%3A-Wish-for-Complex-Model-Generation-tf2725996.html#a7601899 >> Sent from the iBATIS - User - Java mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/Abator%3A-Wish-for-Complex-Model-Generation-tf2725996.html#a7619464 Sent from the iBATIS - User - Java mailing list archive at Nabble.com.
