All good. Yes, for persisting the common lib objects we need to generate the hbm files in the app project. They will be stored in the database of each app project. This makes sense for simple enums and value objects.
/Patrik polly.c.chang wrote: > > Hi Patrik, > > The first usage that you described makes sense. We are using the second > usage that you identified. The "common" project is a library that simply > defines numerous Domain Objects and Enums. There are no Managers or > Services, and the Domain Objects are shared across many applications for > sake of consistency and code reuse. Each "app" project defines its own > Domain Objects that reference the "common" Domain Objects. > > We have currently decided that persisting the "common" Domain Objects is > out of scope for us because not many objects need it, and we are not sure > how best to implement it. I am not sure if the Hibernate mappings for > those tables should live in the "common" project or the "app" project. So > all the "common" objects are currently defined as !persistent > ValueObjects. However, I do think that we may need to be able to persist > some of these objects in the future, such as the Enums. > > I agree with you that using Services instead of a shared database is > better architecture in general. However, sometimes the "library" usage > makes sense too and could require some persistence. > > Thanks, > Polly > > > Patrik Nordwall wrote: >> >> Yes, at first I was a bit skeptical about how the external module will be >> used, and I think it should be used carefully, to avoid too tight >> coupling with between systems (applications). >> >> The overall design principle must be that systems interact with services, >> not with a shared database. >> One possible usage is therefore to be able to refer to an external >> service, including the classes defined as method parameters, return >> values. >> => Classes for DomainObjects, and Servcies belonging to external Module >> should not be generated. >> >> Another usage is that external module is a simple library of common >> classes (DomainObjects). It is not another system with services. This >> means that the application using these classes will be able to store the >> objects in its own database. >> => Hibernate mapping for referred DomainObjects belonging to external >> Module will be generated. The actual java classes will still not be >> generated. >> >> How will you use it? What do you need? >> >> /Patrik >> >> > > -- View this message in context: http://www.nabble.com/-Sculptor--importing-nested-design-files-tp20269181s17564p20316772.html Sent from the Fornax-Platform mailing list archive at Nabble.com. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Fornax-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fornax-developer
