In HiveMind, you could use symbol sources. So, let's say you have a
submodule called "accounting" with a package structure like so:
com.myco.myproject.accounting.domain.repository
com.myco.myproject.accounting.domain.repository.hibernate
com.myco.myproject.accounting.domain.repository.cayenne
So, in your module descriptor, you'd replace the hibernate/cayenne part of
the package with a symbol (something like persistence.strategy). So, (using
BuilderFactory) it'd be something like:
<construct
class="com.myco.myproject.accounting.domain.repository.${persistence.strateg
y}.AccountDaoImpl">
</construct>
James
________________________________________
From: Oscar Picasso [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 23, 2005 4:28 PM
To: [email protected]
Subject: Package and module structure
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 t he 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
