|
Chris,
That
does make sense! I like the idea of putting the version in there so that
you know when you have to upgrade (new version of the software, but db says only
the old version is "installed"). I don't usually create a GUI installer
for my webapps, but then I have never had to package my apps as a "shrink-wrap"
solution for end users. Typically, I make an ant build script where
everything (db, email servers, etc.) is driven off of one build.properties
file. I use Velocity to generate files that are dependent upon values in
the build.properties file. Anyway, I like your ideas!
James
Hi James,
Thank you for the insight on the article. I can definitely see the
advantage of having a UserFactory now.
Regarding the installer idea, it does need a way to check to see if it's
installed or not. The plan that I am using is (in my opinion) pretty
simple. I'm going to have a RegistryService which will work similarly to
the Java 1.4 Preferences API, but will back end on my database. The
InstallerService will use the RegistryService to look up the key
"/system/version". Since directly after installation that key won't
exist, you'll get redirected to the setup wizard. Once the setup wizard
is finished, "/system/version" will get set to the current version (which will
be retrieved through the application default property "system.version").
Using version numbers like that would allow a method for doing upgrades in a
similar manner down the road. Of course, it would be just as easy to
just check for a "/system/installationComplete" key if you don't want to
handle doing upgrades within the application itself.
Does that make sense?
--Chris
On May 3, 2005, at 5:10 AM, James Carman wrote:
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]
|
