I agree that interactions with the DBML designer could have been better from an API level, but frankly developers who are “hacking” the designers are probably last on the LINQ to SQL team’s priority list. I’m not sure if there is any current designer that offers a cleaner API.

Overall I think MSFT could have done a better job at:
1) documenting DBML
2) exposing an object model behind the DBML designer for add-ins to hook into instead of having to update the dbml file directly

The diagram implies that a ‘Return Type’ may indeed play a role those other entities (Access Modifier, ClassModifier, ETC) given that it does not reference a typeID. (Having that optional does complicate things!)

What would you think of objectifying the ‘Type is Return Type for Function’ fact, and naming it “Return Type”? Not that that would make the diagram simpler… Then there’s introducing a third subtype, “return type without typeID reference”… thinking on the fly here. :]

Could you send me that .orm file? I think I’d enjoy mulling it over. It would be a welcome diversion from this medicaid model, and may even give me some fresh ideas for it.

My email is my first name (dot) my last name (at) gmail

1) Yeah, Figure 3 is a bit messy. I wanted to keep the images scrunched enough so they could fit on this page but still be clear. Also, for that page, the semantics of the exclusion constraints are exactly what I need. Unfortunately, a ReturnType may either reference some TypeId or play any of those other roles. I don’t think I can reduce the number of external constraints with subtyping, unless you have any other ideas?

2) Another frustration with this domain is that I can’t subtype here either. If you get a connection string from the XML, then you can still specify a SettingsObjectName and SettingsPropertyName, and if you get a connection string from the application settings, then you can still specify a connection string.

3) I chose to leave primary identifiers off the main object types in this model because they didn’t match the XML representation. I didn’t want people who viewed the model to be confused between a Type’s TypeId (an explicit attribute in the XML which is unfortunately optional) and a surrogate identifier like Type_id. There are also instances of this with FunctionId.

4) Yep, I enjoy the Alignment feature as well. I admit that I should go back and make the models a bit cleaner.

Thanks again for your comments!

I’ve been using ORM for modelling for a few years now, and have a few comments about the models I see:

Figure 3 looks a bit messy. It could be improved by introducing a second subtype of Type, perhaps named “Non-Return Type” or “Regular Type”. Then, attach the facts that do not apply to a return type to it, obviating the need for so many disjunctive exclusion constraints.

Figure two might benefit from a similar subtyping. By introducing an entity to represent the type of location the connection string comes from, (connection string source type) the model becomes more flexible, should there ever be a source introduced that isn’t XML /OR/ application settings.

There were also several entities for which I couldn’t find a primary identifier. I’m thinking you left those off to keep the diagrams from becoming more complex. :]

One of my favorite recent additions to the tool is the ‘alignment’ option - Darren Flynn showed it to me last month. When you select a group of objects on the diagram, select ‘Format’ from the menu bar, ‘Align’, and then how you wish to align them: Lefts, middles, centers, etc.