MikeWitters.com
My $0.02 on stuff.
Unit Testing: The proving grounds for the team
May 8th
After weeks of development a change in a fundamental aspect of the domain has surfaced. To outsiders (read: the business) this change may seem insignificant, but to people who write lines of code, it is understandably a relatively big issue.
Value Objects vs Tool/Framework Bean Req’s
May 8th
A recurring scenario is annoying me. The scenario is this: Create a value object, in the Domain-Driven Design sense, and use it in a Hibernate persisted domain model. Following the DDD style, a value object shouldn’t have a default constructor, because its state should be present upon it’s creation as arguments to its constructor. It should be immutable and have no setters for its state. This won’t work if you’re using any tools/frameworks that require default constructors on the objects in your domain model. Read the rest of this entry »
I’ll be heading to Agile ITX this summer
May 1st
For a long time my career had me doing a whole lot of product installations and integrations where domain models and agile development didn’t necessarily fit. Any conferences or training I attended was based on specific product issues Read the rest of this entry »
Project Breakdown in [Eclipse] Workspaces
Mar 19th
Yesterday, I was doing some refactoring on some code in Rational Application Developer (a derivative of eclipse) and I ended up creating a couple of new projects to house some of it. When I told my colleague he’d need to synchronize with CVS and pull down the new projects he expressed some concern about why I had created the new projects. It made me revisit why I actually did it.
Read the rest of this entry »
Database: Intelligent (Natural) keys versus Surrogate (Blind) Keys
Mar 8th
I’m not a data architect or DBA, but in my current and past positions I, like most software developers, have been responsible for designing schemas for both simple and complex databases. One thing I always waffle about is whether to compose keys from meaningful data or generate surrogate keys for my tables.
I have always been a proponent of using surrogate, or blind, keys. The reason is that I have faced scenarios where what is said to be an iron-clad rule about the business meaning associated with a primary key suddenly changes requiring the need to change that primary key – most DBs don’t handle this well. It’s also cumbersome constructing joins on natural keys when they are composed of several columns. With that said, I do see advantages to having real meaning attached to the fields used as a composite key.
What do you think? Is this a matter of preference of the database designer or is there some rule or advantage that I don’t know of that would be a definite answer one way or another?
Here are a couple of articles to refer to for arguments.
http://www.bcarter.com/intsurr1.htm
http://searchsqlserver.techtarget.com/general/
