Correct, but persistence management services aren't exactly part of your domain model. They are more like support utilities. They are classes that can be used in any application (if they're written correctly).
-----Original Message----- From: Chris Conrad [mailto:[EMAIL PROTECTED] Sent: Friday, June 03, 2005 1:22 PM To: [email protected] Subject: Re: Package structure for domain classes and services James, I'm sorry, my brain seems to have turned off when I typed that. Of course it should be RegistrationServiceImpl and HibernateAccountRepository. I do have some services which use Hibernate directly, but all of them are in my persistence package and are things like TransactionService. I don't feel that using Hibernate directly in persistence management services is a bad thing. :-) --Chris On Jun 3, 2005, at 4:00 AM, James Carman wrote: > 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: hivemind-user- >> [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] > > --------------------------------------------------------------------- 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]
