-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Billeci Sent: Monday, February 07, 2005 10:19 PM To: Chad Brandon Cc: [email protected] Subject: Re: [Andromda-user] Spring Cartridge and Inner Factory classes
Understood. I am considering situations from the view of a customer who may want to extend a class and provide additional functionality but would not have access to the uml models or the capability to generate code. This allows keeping customer customizations relatively isolated from our core product. If we release new versions of our product than customers would have little or no work to migrate their non-UI customizations. Also thinking from a theoretical standpoint where there is a single way to construct business objects. I know there are other ways to achieve these requirements without using Spring. I need to further analyze requirements and see if using Spring for hibernate entities makes sense or not. Thanks for your answers and time. [CB] No problem Richard. If you come up with a good reason (and design within the current cartridge) on how/why we should use spring to manage hibernate entities, feel free to file a JIRA enhancement request :) On Mon, 7 Feb 2005 21:55:59 -0700, Chad Brandon <[EMAIL PROTECTED]> wrote: > > > -----Original Message----- > From: Richard Billeci [mailto:[EMAIL PROTECTED] > Sent: Monday, February 07, 2005 9:47 PM > To: Chad Brandon > Subject: Re: [Andromda-user] Spring Cartridge and Inner Factory classes > > Chad, > > thanks for the quick response. My initial understanding was that > instead of calling: > > (1) new SomeEntityImpl() > > or > > (2) SomeEntity.Factory.newInstance() > > a user would call something like: > > (3) (SomeInterface.class) beanFactory.getBean(SomeInterface.class) > > and that Spring would manage determining what implementation class to > provide. I understand that solution (1) is not good, that solution (2) > provides a level of indirection and is the easiest to understand when > reading code, and that solution (3) requires casting but allows for > easy customization of object construction through the Spring framework > and specifying the implementation class returned through Spring. > > Perhaps I am missing something obvious, but the reason I thought it > adds extra complexity was that if Spring is being used for the DAO's, > why not also use it for the hibernate entities? > > [CB] It doesn't really make sense to have spring manage plain hibernate > entities does it? DAO's and Services both have services that spring can > provide, transaction manage, hibernate session management, etc, but for the > hibernate entities, all we need to do is create a new instance. We don't > need spring to provide anything, so what is the advantage of placing a > hibernate entity in the applicationContext.xml and then having to look it > up? Since we generate each entity every run or AndroMDA, it is fairly easy > to make the implementation class returned by the factory customizable > through an AndroMDA namespace property or something (if we ever needed > that). > > Thanks again. > > On Mon, 7 Feb 2005 21:13:31 -0700, Chad Brandon <[EMAIL PROTECTED]> > wrote: > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Richard > > Billeci > > Sent: Monday, February 07, 2005 9:05 PM > > To: [email protected] > > Subject: [Andromda-user] Spring Cartridge and Inner Factory classes > > > > I have a question about one of the design decisions regarding the > > hibernate code generation for the Spring cartridge: > > > > The hibernate velocity templates for the Spring cartridge produce an > > inner factory class for each hibernate entity generated. My > > understanding is that one of the key benefits Spring provides is to > > allow developers to define factory creation of objects in its > > framework. > > > > [CB] The Spring framework initializes the DAOs and services for the > > application generated by the cartridge, not the hibernate entities. A > > couple of users wanted a clean way to create a new instance of a hibernate > > entity without having to make the call "new SomeEntityImpl()" since that > > call exposes the implementation class of entity. The factory method is > just > > a cleaner way of creating a new instance of the hibernate entity. > > > > The problem that I am having is that I do not see the reason for using > > the factory pattern when MDA and Inversion of Control is used. Adding > > factory classes seems to add extra weight and complicate the design in > > my mind. > > > > [CB] How exactly does it complicate it? > > > > I am still reading about and experimenting with the Spring framework > > so I don't know all of its limitations yet, but what am I missing? > > > > Best Regards, > > > > Richard Billeci > > Metagee Europe GmbH > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real users. > > Discover which products truly live up to the hype. Start reading now. > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > _______________________________________________ > > Andromda-user mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/andromda-user > > > > > > ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Andromda-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/andromda-user ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Andromda-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/andromda-user
