WorkItem Object Mapper

First Thoughts

Page history last edited by Bernardo Heynemann 3 yrs ago

BHAL Project Home Page / Documentation / First Thoughts /

First Thoughts (By Bernardo Heynemann at 23-Sep-2006)

I was considering the reasons why we needed ORMs, since we could all just use ds.Tables["0"].Rows["0"]["ColumnName"] (Forgive the quotes here, it´s a wiki issue) and keep using Sql Statements. This worked, but it wasn´t maintainable.

The WorkItem model is fantastic, but it relies on untyped string-named fields. This became evident once I started to model the CreateWorkItem Activity on Project BHAL. I didn´t knew what fields to add to the activity, mainly because a WorkItem isn´t typed. It can have any number of properties (only a few of them are fixed). You can´t trust not even the WorkItemType, since CodePlex, for instance, uses a single WorkItem Type called "Work Item" and differentiates them by a custom property that can have the values of "Issue", "Task" and "Feature".

So, at this point I was thinking about doing a Dictionary<string,object> Properties kind of thing. And it was at this point that the ORM experience hit me. If we do a <string, object> architecture and them we build a whole business layer (the workflows) on top of this untyped structure, what happens if a WorkItem changes it´s structure (similar to a DDL operation)? Well we must recheck every single one of the WorkFlows, and possibly every code that interacts with it, because our solution lacks a great feature of the current development languages: Compile-Time errors. We won´t catch the errors until runtime! And that´s IF we catch the errors before our customer does (even being an internal customer).

So I did a little bit of thinking and came up with an alternative solution: The WorkItem Object Mapper. We would build a WorkItem object library, pretty much in the same way as we did a data layer object library and then the only thing left to do will be decorating the WorkItem properties with a [WorkItemProperty(" MyFactory.WorkedHoursOnThisTask")] or something like that.

The WorkItem object mapper would then help in a few repetitive tasks, such as:

-Connecting to a WorkItem Store, by using similar Configuration to the config:

TFSServer server = Wom.ServerFactory.GetTFSServer();

--Retrieving a WorkItem

Bug bug = new Bug(1023); //since bug inherits from Wom.WorkItem, it implements a constructor that gets a WorkItem by it´s id.

--Saving a WorkItem

Bug bug = new Bug(1023);

bug.Priority = Priorities.High;

Save(bug);

Since the BugManager class inherits from Wom.WorkItemManager, it implements Save, Delete, Close, and any other helper methods possible.

-Maybe even add Transaction support:

BeginWorkItemTransaction();