hivemind-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oscar Picasso <oscgoo...@yahoo.com>
Subject Package and module structure
Date Wed, 23 Nov 2005 21:28:05 GMT
Hi,
 
 I read an interesting thread some time ago about "What would be a service?" and "Package
structure for domain classes and services" (see http://thread.gmane.org/gmane.comp.jakarta.hivemind.user/1010).
 
 The package/module structure is for me always an unresolved question.
 
 Let's take a simple example for managing users.
 You can have:
 
 ++ domain
 - domain interface: User
 - domain class: CayenneUser
 If all persistence strategies could use directly POJO, I should not need to separate between
interface and implementation. However, cayenne for example requires that your persisted object
is a subclass of CayenneObject. So that's the way I have found to avoid dependency on the
cayenne persistence framework.
 
 ++ persistence
 - dao: UserDao
 - dao implementation: UserCayenneAccess
 I usually also create a CayenneAccessManager to easily switch between persistence strategies
but maybe there are some better ways to achieve this goal with Hivemind.
 
 ++ service
 - service: UserRegistration
 - service implementation: UserRegistrationImpl
 
 One possible and obvious package structure would be:
 org.mycomp.domain
 org.mycomp.domain.cayenne
 org.mycomp.dao
 org.mycomp.dao.cayenne
 org.mycomp.service
 org.mycomp.service.impl
 
 This kind of structure makes the life easier for the developer/implementor. You can easily
change your persistence strategy by replacing org.mycomp.domain.cayenne with org.mycomp.domain.hibernate
and changing you dao factory (for example using an HibernateAccessManager instead CayenneAccessManager).
 
 As am always eager to try new frameworks and strategies, I usually choose this structure.
I think, even if it's just a guess here, that you could put you persistence implementation
in a separate module/jars and use hivemind to select the right implementation.
 
 However this kind of structure tends to hide the real business model. 
 
 If I need to solve the business problems related to the users I need to look at 6 different
packages.
 
 For a more business centric point of view I would prefer something like:
 1- if you prefer a view of your project based on the domain model
 org.mycomp.user
 org.mycomp.products
 ...
 
 2- if you prefer a view of your project based you project based on the use cases:
 org.mycomp.register
 ogr.mycomp.sellproduct
 ...
 
 Both of these structures are closer to the business problems you try to solve. Everything
related to respectively an entity or a use case is in one place. On the other hand it makes
it more difficult to change the implementation of a layer (for example to switch to another
persistence strategy).
 
 Ideally I would like to have a business centric layout while still retain the ability to
switch easily between strategies for some layers like the persistent layer.
 
 Any idea if such a goal is reachable?
 
 I that case what would be the packages/modules structure? 
 
 Thanks 
 
 Oscar
 


		
---------------------------------
 Yahoo! FareChase - Search multiple travel sites in one click.  
Mime
View raw message