Chris, I haven't looked at the code for AppFuse, but in my opinion, any implementation class that has "Hibernate" in the name should probably be a repository/DAO, correct? Service implementations should not use Hibernate directly. The Hibernate specifics should be hidden by your repository implementations. So, in your example below, you have a class called HibernateRegistrationService. I would think you should have HibernateAccountRepository (I like using Hibernate rather than Impl, too) and RegistrationServiceImpl (which uses an AccountRepository to add Account objects to the system) classes. That's how I set up the structure of my example application for my article as that made the most sense to me. The registration logic should not need to change when you change persistence strategies (like switching to JDO for some crazy reason). Only the implementations of the repositories would need to change. Agreed?
James -----Original Message----- From: Chris Conrad [mailto:[EMAIL PROTECTED] Sent: Friday, June 03, 2005 1:07 AM To: [email protected] Subject: Re: Package structure for domain classes and services Hi Eyon, On Jun 2, 2005, at 7:36 PM, Eyon Land wrote: > Wow AppFuse is impressive! > > It looks like the appfuse package structure is setup > similiar to the way James described... > > org.appfuse.dao (dao interfaces here) > org.appfuse.dao.hibernate (hibernate implemenation > instead of just "impl") > org.appfuse.model ("entity" classes and POJO classes > used on presentation layer...hummm) > org.appfuse.service (service interfaces) > org.appfuse.service.impl (implementation) > > Chris, > Was this the style of packaging you did not like? Did > I misunderstand? That is the packing structure that I don't like. > >> From your comment it sounds like you would do >> > something like... > > org.appfuse.account.dao (account dao interfaces here) > org.appfuse.account.dao.hibernate (account hibernate > implemenation instead of just "impl") > org.appfuse.account.model (account "entity" classes) > org.appfuse.account.service (account service > interfaces) > org.appfuse.account.service.impl (account service > implementation) I would actually do: org.appfuse.account org.appfuse.account.impl Everything which should be exposed to other modules/clients would be in org.appfuse.account. That might include an Account entity, and AccountRepository and a RegistrationService. All of the internal implementation related stuff would go into org.appfuse.account.impl. That might include AccountRegistryImpl and HibernateRegistrationService. In my application at least, the individual modules aren't large enough to need to break things up further than that. Now, that said, I do break my own rules from time to time. An example I can think of offhand is my persistence module. In that I have: myapp.persistence myapp.persistence.hibernate In that cause, I use hibernate instead of impl because all of the implementation classes specifically use hibernate. Hope this is helping someone, but please note that I'm not advocating this as the one true way to structure applications, just one way that I've found keeps things organized. --Chris > > org.appfuse.itinerary.dao (itinerary dao interfaces > here) > org.appfuse.itinerary.dao.hibernate (itinerary > hibernate implemenation instead of just "impl") > org.appfuse.itinerary.model (itinerary "entity" > classes) > org.appfuse.itinerary.service (itinerary service > interfaces) > org.appfuse.itinerary.service.impl (itinerary service > implementation) > > > <Chris, your comment below...> > Just to throw my two cents in here, I've never liked > this style of packaging, it doesn't tell me anything > about the structure of the application. I've always > done my packaging based on distinct feature sets or > modules in the application. For example, I'd have > com.myco.account package which contains all the > entities, services and repositories which are > "publicly" exposed and relate to account management. > Then I might have a com.myco.account.impl package > which contains implementation specific stuff that > shouldn't be used by anyone outside of the account > module. This makes the boundaries between different > sets of functionality in your application clear. On > the flip side, it does tend to create packages which > my have only 1 or 2 classes in them. > > --- Glen Stampoultzis <[EMAIL PROTECTED]> wrote: > > >> On 6/3/05, Eyon Land <[EMAIL PROTECTED]> wrote: >> >>> Do you have a "hello world" example that >>> >> demonstrates >> >>> the kind of packaging you are proposing? Maybe >>> >> this >> >>> would be a good example to have for any HiveMind >>> >> user? >> >> Hivemind in general needs some more (and better) >> examples in general. >> >> Take a look at AppFuse. It uses spring but is a >> good example of _one_ >> way to structure an application using DI. >> >> >> > --------------------------------------------------------------------- > >> To unsubscribe, e-mail: >> [EMAIL PROTECTED] >> For additional commands, e-mail: >> [EMAIL PROTECTED] >> >> >> > > > > > > > __________________________________ > Discover Yahoo! > Find restaurants, movies, travel and more fun for the weekend. > Check it out! > http://discover.yahoo.com/weekend.html > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
