Chris,
As for your comments on the article, yes the
UserFactory service was a bit too "thin." But, I wouldn't necessarily
suggest removing it. I structured the code for the article based upon
principles from the book Domain Driven Design: Tackling Complexity in the
Heart of Software by Eric Evans. In the book, Evans prescribes the use
of entity "factories" to hide the complexities of object creation. In my
example, though, there wasn't much complexity to hide. Factories are
supposed to be used when creating a single "aggregate" object involves creating
many other objects. The logic doesn't belong inside the constructor.
Nor does it belong inside the client code which needs the object to be
constructed. But, it does belong inside the "domain." So, factories
are introduced. As I said, my example didn't really require the use of a
factory, but the User class would be an "aggregate" in a real system and
creating one would involve creating other objects (Roles, Addresses,
etc.). If you design that way from the beginning, you don't have to
refactor later when you need a factory (finding everywhere you used the
constructor directly). Using the factory,
however, did make my unit testing easier. I merely had to tell my
mock factory which object to return, avoiding the use of "argument matchers" and
the like.
As for your other stuff, it sounds rather cool. The trick would be making your installer service know that the application has already been installed, across restarts. You could put something into the database, I would imagine, to make that flag more permanent. I think it's an interesting idea.
James
-----Original Message-----
From: Chris Conrad [mailto:[EMAIL PROTECTED]]
Sent:
Tuesday, May 03, 2005 1:45 AM
To:
[email protected]
Subject: Designing with Hivemind best
practices
I'm hoping that maybe we can strike up a discussion on some
design
best practices when working with Hivemind. Unfortunately,
I'm not
the one to do much talking, but I'd like to pose some questions
that
might get the ball rolling.
After reading through The
Server Side article and the documentation
it's my understanding that
Hivemind services should small and fine
grained. Assuming that
I've got that aspect correct, my question
would be, what is too
small? For example, in the article there is
a
RegistrationService, UserFactory and UserRepository. If I was
to
start a design from scratch the most logical design for me would
be
to combine the RegistrationService and UserFactory into a
single
UserService and then keep the UserRepository as is. How do
you guys
decide when a service is fine grained enough, or in the
alternative,
what is too fine grained?
My second thought topic
involves application installation. I'm going
to use a standard
J2EE web application for examples sake. From my
experience, you'd
first set up your container as necessary (database
connections,
javamail sessions, etc.) and then deploy your war or
ear. At that
point, however, most applications still have a good
amount of
application specific that still needs to be done. For
example,
setting up default preferences, creating the first admin
user,
etc. In the past I've simply had all of that in the database
sql
initialization scripts. It seems to me, however, that
Hivemind
presents some interesting opportunities to make this more
user
friendly. For example, an InstallerService could have a
contribution
point which takes Installer services. These can
provide (if we were
using Tapestry) a Tapestry component and
label. The InstallerService
can use a Wizard component which
pages through the different
Installer component contributions.
The individual Installer
components could use ApplicationDefaults for
the default values.
Then the Tapestry front end can check with
the InstallerService to
see if installation is complete. If it
isn't, it can redirect to the
wizard which allows the user to do the
initial configuration.
Hopefully this isn't too off topic for the list,
but I'm really
interested in what people think about these
things.
--Chris
---------------------------------------------------------------------
To
unsubscribe, e-mail: [EMAIL PROTECTED]
For
additional commands, e-mail:
[EMAIL PROTECTED]
