I might be barking up the wrong tree here but I'm coding my app and finding that I'd love to be able to pass around various primary key values as my own custom type. Most of my primary keys are Int32's and if I could type them individually for every table/entity that they are used for I would be able to:

1) Be able to define multiple signatures for Business Layer class methods that take a primary key as a parameter.

2) Generally, reduce bugs by virtue of type-safety.

An example of 1) from my App is "GoalsTree.Populate(int userId)" where I'd like to also 'Populate' the GoalsTree for a given Project or for a given Organization instead of for a User. So, "GetGoals(int projectId)" and "GetGoals(int organizationId)" would become "GetGoals(ProjectId projId)" and "GetGoals(OrganizationId orgId)".

I guess most readers are thinking, why not pass around an Entity object! I'm not sure I like that idea since the Entity represents the actual data and not the ID to one. Since these id values might be long-lived I don't really want Entity object implementations of them floating around. Also there is the cost of constructing and filling one of these objects when I actually didn't want to retrieve the data from the database. And memory, etc...

I think this is all doable using the llblgen Type Converter feature and .NET TypedConverter class which I am reading up on now.

Thoughts? Am I missing something (afterall this is my first .NET app!)? If I did this would I be adding runtime overhead at either the app level or at the llblgen runtime lib level?

If this is your first .NET app I would try using the software without this functionality and see if it makes sense or not after you get a little experience with the code. I would think that you wouldn't get much use out of this scenario in general, but a lot of maintenance when creating a new table.

Thanks for the advice.