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]
