Linq to SQL code generator features

1
votes

I'm very fond of Linq to SQL and the programming model it encourages. I think that in many cases when you are in control of both the database schema and the code it is not worth the effort to have different relational and object models for the data. Working with Linq to SQL makes it simple to have type safe data access from .NET, using the partial extension methods to implement business rules.

Unfortunately I do not like the dbml designer due to the lack of a schema refresh function. So far I have used SqlMetal, but that lacks the customization options of the dbml designer. Because of that I've started working on a tool which regenerates the whole code file like SqlMetal, but has the ability to do the customizations that are available in the dbml designer (and maybe more in the future).

The customizations will be described in an xml file which only contains those parts that shouldn't have default values. This should keep the xml file size down as well as the maintenance burden of it.

To help me focus on the right features, I would like to know: What would be the most important features in a linq to sql code generator?

1
linq-to-sqlcode-generation
This is a marginal question for SO. Consider the reaction that MS would get if they started gathering information on usability via SO for their products. At the very least it ought to be community wiki since there is no way to definitively answer it. – tvanfosson
FYI - I have an add-in for Visual Studio that adds some missing features to the designer. (control over class and property naming, mass-renaming, model <-> db sync, class and property documentation through xml-comments, etc). Check it out at huagati.com/dbmltools and see if it fits your needs. – KristoferA

1 Answers

1
votes

Not sure if this is what is you're looking for, but here's some features I'd like to see:

  • The ability to assign a enumerated type to a foreign key field. So if your "Item" table refenences a "ItemType" table, have the ability to easily assign an "ItemType" enumeration to that relationship, so that when you access the get/set property you get the strictly typed enumeration instead of the ID a record in another table. I think you can do this in the .cs file that is generated by the DBML designer, but of course it gets blown away the next time you re-add the table to the designer. Also, you can add a new property in the partial class that maps onto the ID field, but it would be nice if this was done natively in the designer.

  • In the case of FK relationships, have it name the property based on the FK field name or FK constraint name. For example, if your "Item" table has a "CreatedByUserID" and "UpdatedByUserID" fields that both reference the "User" table, the LINQ DBML designer will created an Item class with properties named "User" and "User1", so you almost have to guess which is the created by and which is the updated by (and hopefully add additional, more explicit properties in the partial class). How you would go about generating those names would get a little hairy, but anything is better than what they have now.