Starbucks-fueled Developer

Tuesday, April 12, 2005

Reflection on Repository

I looked into Jeffrey Palermo's architecture and, just about like anyone else new to TDD, I questioned "all the code". Unlike everyone else, however, I did not question the code for the tests; I had problems with all the code for mere data access.

Palermo's architecture makes use of Fowler's Repository pattern and that's mainly when flags were raised for me. Fowler states in describing the pattern that "a simple extension of the Repository pattern allows different querying strategies to be employed depending on the situation." [Fowler, Patterns of Enterprise Application Architecture, 2004]. Part of me wonders if he should've just flat said "if you implement this pattern abstractly (interface or base class), it allows for a more testable design" and left it at that.

But, unfortunately, my mind doesn't just accept that possibility alone and continues to wonder: what's the value of this outside the unit testing fixtures? I'm hard-pressed to imagine a situation where an application would need multiple data access strategies for the same domain objects.

On top of all that, Fowler mentions that the Repository pattern removes the query mechanics from the client and allows the code to be less dependent upon itself. I'd really like to see an actual implementation of this pattern using NHibernate since it incorporates the Query Object that Fowler describes and I feel it would put the pattern in better perspective.

I am not trying to take the position that this is not a useful pattern and/or that it should be abandoned. I completely agree that applying the Strategy pattern with the Repository allows for extremely testable code. However, any time I've entertained implementing the Strategy pattern it almost always seems as though it comes up as more of a "plug-in" or "provider" implementation. By this I mean that I feel the need to dynamically determine, based on domain data, configuration settings, etc., and Palermo's architecture doesn't fit that description. The tests use statically mocked/stubbed objects to ease the work the testing framework has to do in order to still perform valid execution of the code under test.

Finally...what about the security implications of exposing all the "core" architecture as interfaces or other abstract OO methods? For example, in Palermo's architecture, the ConfigurationService object provides a read/write property for the IDataProvider. I understand needing the write accessor so that the Repository can be mocked, but, to me, it seems as though the code is "more vulnerable" because malicious code could possibly dynamically reflect on the application and inject a malicious implementation of the IDataProvider. This is not to say that I feel that dynamically creating types from the applications configuration file is completely secure and is the only way to go. It just seems to me that it exposes the code more and violates the "minimize the attack surface of the code".

(disclaimer: I do not claim myself to be a security guru nor do I "real" developer with any "real" knowledge of anything "real", don't take it all with a grain of salt...)

Am I completely off base with all this?

Monday, April 11, 2005

Check In Importance

So I learned the hard way today why frequent builds and check-ins are so important and key to the XP methodology.

My boss asked me today to review my time submitted for the prior week as she wanted a more detailed report for billing purposes. "Sure, I'll review my comments in VSS to make sure I didn't miss anything and get you more accurate numbers".

The screaming you heard, yeah, the incredible pain from shooting myself in the foot.

Several files in the project that I am working on, nearly exclusively, were checked out for longer than a week without comments etc. added to detail the follow of work or track the changes to the code. Oy...

Learning to be a pragmatic programmer is a whole lot tougher than I thought...

Friday, April 08, 2005

Jeff Palmero's TDD Presentation

I have been conversing off and on with Scott and I am looking to give a similar talk/presentation to my coworkers. I'm already anticipating the questions and concerns that were addressed in your meeting; they seem to be pretty prevelant throughout the community whenever TDD is mentioned.

I, too, am just starting to attempt to pick up this methodology and it can be quite daunting to say the least. One of my personal struggles is also feeling the need to learn OO design at the same time, particularly the GoF material. Hard stuff to swallow all at once...

For my talk, I'm struggling to come up with a good demo. One that the audience will be able to grasp and sink their teeth into. I'd really be interested if anyone has any input as to good, simple sample applications for TDD demo purposes.

My first Test-Driven Development presentation - and concerns raised - level 100

XP SP2 makes it a snap to disable the Shockwave add-in - level 000

The only thing that would make this any cooler is if it was enforced corresponding to the Zone, like Trusted Sites, etc. For example, say I'm browsing and there's a flash ad coming from adkami or whomever they are. IE would notice that it's coming from a different site and block the ActiveX control from running because it could potentially load malicious content.

Now that would be sweet!!

XP SP2 makes it a snap to disable the Shockwave add-in - level 000

Wednesday, April 06, 2005

Strategic Policy Entity

So, in talking to Scott, I still feel a little left in the dark...

Call it mind-numbing anal-retentiveness, I'm having a hard time accepting the fact that an object that fits the STRATEGY pattern could also be an Entity. I guess I feel that business logic should be as far from the Entities as possible and that by giving an Entity more responsibility then just a container for data seems like departing from the model-driven design terminal into limbo, honestly.

How would you classify such an object? A strategic policy entity?

Maybe I don't undestand this at all...


I noticed in reading my previous post that I'm not that great of a writer - that post was all over the place!!!

You'd think I would have got more out of my Lib. Arts. education...

Aggregates, Ho!!!

I discovered my first Aggregate!!! Cha-ching!!! Finally, all this model/test-driven design research has "paid off"...

If only that were the case.

In finding the Holy Grail of OO design, I also found that my persistance layer, drafted ever-so-horribly by yours truly, doesn't appear to easily accomodate such a design...

Thinking about this more, however, has posed an interesting question: why should the persistance layer care about Aggregates? Unless I'm terribly missing something, the mechanism by which objects are persisted shouldn't have an knowledge or interest of what an Aggregate is or what objects compose which Aggregates...Right?

I think I'm still stuck on the same path that I was before I took that blogging hiatus. Here (I hope...) is an Aggregate scenario that has me stuck in the "Procedural Age". I wish I was able to write this out as a User Story but, unfortunately, I'm just not there yet...

In a Product/Inventory System, you need a method of abstracting all the different kinds of products you're going to be selling. Hense, the Product class is born. Each product type (more on this to come) subclasses Product so that they inherit all the necessary/required data and add their own. For Example, Book subclasses Product and adds properties like ISBN and Title and inherits Product Number and Description.

Here's where, I feel, it gets ugly...In fact, I'm sure some will cring in reading this but I'm not sure how else to convey what I'm thinking :)

Let's say there's some business rule that says, "If it's a Book, the Price has to be at least $15". Again, as a developer from the "Procedural Age" my code gets...well, knarly...trying to apply this business logic in the UI. It's like I need a Product Type object, or something, that says "hey, this is a Book, so we need to make sure the Price is at least $15". I say that I need a Product Type object because this is precisely the kind of data that the users maintain; the company gets a new CEO and he says "nope, if it's a Book, the Price needs to be at least $10 because we're not selling enough of them". By creating this Product Type Entity, the users are then able to update it ONCE, effect each appropriate Product, and not have to issue a change order to my company because we hard-coded the validation "If Book.Price < $15 Throw New ArgumentOutOfRangeException()"

So I have Product Type, Product, and all my subclassed-Product entities...This is an Aggregrate, correct? I cannot create a new Product if I do not also assign it a Product Type...I almost wrote "Create a new Product Type"...Wow...Am I getting lost in all this...

The Bottom Line

In my scenario above, each Product Type helps determine how to further validate new Products. However, since I decided to build my Products by subclassing from a base object, I already have "types". If I combine the information that I'm looking to store in my Product Type entity into the Product entity, I believe that will produce duplicate data as every time a new Book is created, the user will be forced, in this scenario, to re-enter the values for determining a valid Price.

Where do you draw the line?!

Try this again, shall we?

I'm back, not necessarily better than ever, but the hiatus is over and posts are coming...

Check back often.