This page needs to be used to come to a decision on how we're structuring and passing our data out of the logic layer to where the controls can get to it. Based on previous discussions we have three main options out there.

Proposed Implementations of Data Representation Model

  1. Custom-written Object Model
  2. StronglyTyped data sets AS an object model
  3. Team Foundation API elements.

Proposed Relational Model

ObjectMap.PNG

Eric -> I'm currently only viewing 1 and 2 as options at this time, unless there's some other API out there for Team Foundation besides the objects in Microsoft.TeamFoundation.VersionControl.Client. Those objects are GREAT for querying the data, but don't appear to be well suited for representing the data for passing around between layers. They also don't provide the protection we desire against API changes.

Regardless of what we decide, I think the relationships need to look like the image above.

As for deciding which one to use, I've got to still push on the DataSet approach. I know we're not getting our data from a database (at least, not directly), but it IS relational data and the data set gives us the basic access and representation for very little development cost. It also doens't limit us, as it's very easy to add additional code to it using partial classes.

Eric -> Ooops - in the diagram I forgot to include the ParentBranchSpec on to represent the tree structure of the branches. I realized it on my way home, so I'll try to get that in there sometime Monday.

Steve -> I'm not sold on the typed-dataset yet. I haven't used them in 2005 yet, so I'll reserve judgement there, but I've had some bad experiences with them in 2003. I know that we will get a speed boost out of the gate using them, but will it limit us later if/when we want to slap on a different UI? I'm specifically referring to a web service. Datasets have a lot of overhead associated with the features they offer that we just aren't going to utilize. We're really just moving data up to the UI for display so wouldn't a small object graph using generic collections would do the trick and be more lightweight?

Eric -> Honestly, I'm not entirely sold on either approach, but we DO need some level of table semantics, and we're going to need n->n assocations between labels/workitems and the versioned items. I guess in this case I'm looking at it from the opposite side of "Yes, they may have performance and/or memory overhead, but none of our use cases are for performance-limited environments" Besides, "out of the gate" is probably the most important place to get a speed boost - we need some momentum :) I've written the sample code to populate the DS, just need to productionize it.

MR -> On the versions entity... Have you validated that is a proper representation as in VersionItemSpec, BranchItemSpec and Changeset? Is there any uniqueness in a table of that data or is it wide open? That entity has me a bit confused.

Eric -> I initially intended to refer to it as an SCC path - $/Blah/blah.bleh because the server-side ID's don't really have meaning to us. However, it may not be needed. I'll need to look at it again when I'm at the office with a few free minutes. As far as I know, though, the combination of source control path and changeset should be unique. It's common that the same file on multiple branches would change in the same changeset, but I think adding the path in some form would make it unique. I think we do have to keep the BranchItemSpec (FK to branches) because it's a valid (although strange) scenario where a dev branches a file, then does a pair of moves to swap their position.

Last edited Jul 20, 2006 at 4:44 AM by erwilleke, version 8

Comments

No comments yet.