You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@hivemind.apache.org by Eyon Land <my...@yahoo.com> on 2005/06/03 04:36:51 UTC
Package structure for domain classes and services
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?
>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)
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 <gs...@gmail.com> wrote:
> On 6/3/05, Eyon Land <my...@yahoo.com> 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:
> hivemind-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> hivemind-user-help@jakarta.apache.org
>
>
__________________________________
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: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
RE: Package structure for domain classes and services
Posted by James Carman <ja...@carmanconsulting.com>.
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:cconrad@vasoftware.com]
Sent: Friday, June 03, 2005 1:22 PM
To: hivemind-user@jakarta.apache.org
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:cconrad@vasoftware.com]
> Sent: Friday, June 03, 2005 1:07 AM
> To: hivemind-user@jakarta.apache.org
> 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 <gs...@gmail.com> wrote:
>>
>>
>>
>>> On 6/3/05, Eyon Land <my...@yahoo.com> 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:
>>> hivemind-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail:
>>> hivemind-user-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>> __________________________________
>> 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: hivemind-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: hivemind-user-
>> help@jakarta.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
Re: Package structure for domain classes and services
Posted by Chris Conrad <cc...@vasoftware.com>.
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:cconrad@vasoftware.com]
> Sent: Friday, June 03, 2005 1:07 AM
> To: hivemind-user@jakarta.apache.org
> 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 <gs...@gmail.com> wrote:
>>
>>
>>
>>> On 6/3/05, Eyon Land <my...@yahoo.com> 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:
>>> hivemind-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail:
>>> hivemind-user-help@jakarta.apache.org
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>> __________________________________
>> 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: hivemind-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: hivemind-user-
>> help@jakarta.apache.org
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
RE: Package structure for domain classes and services
Posted by James Carman <ja...@carmanconsulting.com>.
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:cconrad@vasoftware.com]
Sent: Friday, June 03, 2005 1:07 AM
To: hivemind-user@jakarta.apache.org
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 <gs...@gmail.com> wrote:
>
>
>> On 6/3/05, Eyon Land <my...@yahoo.com> 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:
>> hivemind-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> hivemind-user-help@jakarta.apache.org
>>
>>
>>
>
>
>
>
>
>
> __________________________________
> 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: hivemind-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
Re: Package structure for domain classes and services
Posted by Chris Conrad <cc...@vasoftware.com>.
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 <gs...@gmail.com> wrote:
>
>
>> On 6/3/05, Eyon Land <my...@yahoo.com> 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:
>> hivemind-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail:
>> hivemind-user-help@jakarta.apache.org
>>
>>
>>
>
>
>
>
>
>
> __________________________________
> 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: hivemind-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: hivemind-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: hivemind-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: hivemind-user-help@jakarta.apache.org