It seems that Justin and I are on the same track again...

Yet Another O/R Tool.

In my quest to find an O/R tool, I have spent some time with the O/R tool called ORM.NET. Unlike other toolkits that have you annotate your code with attributes or generate an XML mapping file, ORM.NET actually generates the code that will become your data access layer.

Now the reason I looked at this toolkit is because of their FetchPath construct. Basically FetchPath allows you to state which objects should be returned in the query. So using the examples I've been using, I could pass in something like this - FetchPath.LineItem.ServiceRequest.Lot. And this would instruct the code that is generated to return LineItems, the parent service requests, and the parent lots. The cool thing about it is that the FetchPath is a params parameter. So I can pass in multiple FetchPaths as long as they are related to the root object (LineItem in my example) or in one of the objects returned.

So it looks like it does what I want. But it does too much. There are some relationships in my tables that I don't want exposed. For example, we have the concept of a security context that can contain other sub-objects. I have foreign keys on these context columns and therefore ORM.NET generates code for them. And I can't seem to find a way to remove those "Parents".

But given that the DB schema I'm working off of is several years old and has had many, many hands touch it. I wasn't expecting a clean layer to be generated. But I probably would consider it for other projects that I'm working on.

[News from the Forest]

I'm lucky enough to spend most of my time working on greenfield applications, so this tool may be better suited to what I'm doing. As I said a couple of posts back, I'll let you know what I decide.