| 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]
|
