Repository structure thoughts

Question

We are working on what seems to us a moderately large project, which we
have divided into subsystems. We have partly decided on and partly
evolved into a structure where each subsystem has one or more of the
following projects (where "subsystem" is the name of the subsystem):
subsystemConst - This project contains manifest constants, defined at
the project level.
subsystem - This project contains business classes (and kin) and
persistence classes and their associated SOs. The decision to
put persistence objects in the same project with the business
objects was to allow "lazy instantiation" in a reasonably
encapsulated form. But I don't know that we have made a lot of
use of this.
subsystemPM - This project contains policy classed, and their service
objects.
subsystemReports - This project contains all the reports relative to the
subsystem.
subsystemWidget - This project contains graphic widgets related to the
subsystem. We evolved into this because of the desire to have
subsystems use each others' widgets (e.g. self-populating
selectors) without either dragging along all of the other
subsystem's window classes or running into circular project
relationships (which we have dubbed the "I'm my own grandpa"
problem).
subsystemWin - This project contains the window classes, plus any
non-window classes that are intimately tied to windows (e.g.
dispatchers, display variants of business classes, and so on).
The supplier relationships are generally top-to-bottom in this list
(except that there are probably no cases where "Reports" supplies
"widgets"). Among subsystems things get a little trickier. Although it
is usually obvious that subsystem "A" should supply subsystem "B", at
times things are not that simple. These cases have ususlly been solved
by being flexable about subsystem membership and ownership. So even
though class "C" was specified as part of subsystem "B", and is written
by the "B" implementer, it gets put in a project for subsystem "A" if
that's where it fits better in the scheme of things. A few truly
pathological cases have been dealt with at the persistence level, by
allowing a persistence class of project "B" to read, BUT NOT WRITE, data
normally belonging to "A".
In addition to the above, there are a number of utility classes, grouped
into projects in a semi-logical manner. Generally we try to keep these
fairly high in the suppliership hierarchy (i.e. they supply 'most
everybody, but nobody much is allowed to supply them).
As I say, this has worked OK so far, but I truly believe that there is
no universally best way, and Newton's third law of consulting ("For
every consultant there is an equal and opposite consultant") definitely
applies here. You just have to weigh the advantages and disadvantages,
go with what looks good, and be prepared to adjust as needed. As for the
plan described above:
Advantages:
* Small projects (which is partly a religious issue, but given Forte's
continued lack of a really good browser, it seems to have
practical advantages in finding the class you want among what
must by now be a thousand or more).
* Lazy instantiation works. Though, as I said, I'm not sure how much
we're taking advantage of this.
* You don't have to partition the entire application just to test your
corner of it.
Disadvantages:
* The decision to put SOs in the same project as other objects may have
prevented us from using loadable libraries.
* We had a Forte consultant a couple weeks ago recommend an approach we
have dubbed "the mother of all persistence objects" to increase
concurrency of database access and therefore scalability. He
recommended the "two or three humongous projects" approach based
on this, but failing that we create a project which is supplied
by any and all projects containing persistence classes, make
each of these private attributes of the "mother" object, and
then give the "mother" stub methods to call the correct
persistence object method. We are still considering this, but it
will obviously break any lazy instantiation we have done.
Tom Wyant

Answer 1

Hi,
If you want to move the contents of the BEA repository from Portal A to Portal B you can do so with the propagation tool. Please contact CCE/Support to get a copy of it.
Regards,
--alex