[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ormf-dev] Refactoring of org.eclipse.ormf.server.base
|
On 10 Oct 2008, at 10:13, Achim Loerke wrote:
Joel Rosi-Schwartz wrote:
Hi,
I am working on the migration to OSGi. Presently
org.eclipse.ormf.server.base has a non standard structure which is
a legacy of how we organised Useme. I am thinking along the lines
of abandoning the project (it is not even a plug-in) and creating
several new projects for the OSGi bundles that we represent the
server. Here is the layout I am considering:
org.eclipse.ormf.server.base.common
org.eclipse.ormf.server.base.services
org.eclipse.ormf.server.base.persistance
org.eclipse.ormf.server.base.publisher (or possibly reporting?)
reporting seems a better recognized term.
Agreed and is more generic which is good thing for us. In the end we
may (or may not) end up with a specific "publisher" bundle which
depends on the reporting bundle and is responsible for creating the
artefacts as "documents" versus general reporting. In any case it is
too early to start architecting the reporting system...
org.eclipse.ormf.server.base.xxx (as required)
Thoughts?
I haven't checked how close the packages are coupled. From my
experience putting packages in different plug-ins supports a better
decoupling (between classes). This leads to a much better
maintainability. The problem here is that there is an existing code
base. You have to be very careful where to move packages or you will
end up with a load of "buddy class loading" or non-intuitive
factories and interfaces.
From the naming of the packages I guess that "common" is the base,
"persistance" depends on "common" and that "services" and
"publisher" are based on "persistance" and "common". This would work
well. If part of the business logic is in the "persistance" and/or
"common" package things won't work out this easily.
You are absolutely right of course. As much as possible I want to keep
cross bundle dependencies as services rather than class usage. Of
course some objects, f.i. returned business objects, need to be
exposed but these will be via their API, i.e. interfaces. This should
be fine for "persistence" but "common" of course is another story. My
goal is to keep all of the business logic in persistence in the first
instance and refactor it out its own bundle(s) later as we are clearer
on the API.
Joel
