If you’ve used Visual Studio for any length of time, you undoubtedly make heavy use of refactoring. Even the simple refactoring of renaming a class or method and having Visual Studio automatically update all references is a huge time-saver. If, however, you use the LINQ to SQL or Entity Framework designer, and you rename a class or property in the designer, the references to that class or property in your code don’t get updated: you need to go through and fix them up by hand. Until recently, we admit, that’s also been the case in the LightSpeed designer. But not any more!
In current nightly builds, you can right-click an entity or property and choose Refactor > Rename. LightSpeed will then not only rename the entity or property, it will also update any existing references. The Refactor > Rename command also gives you the option to keep the existing name as the “database name” (the Table Name for entities, the Column Name for properties), so that you don’t need to remember to remap the entity or property by hand. (Of course, you’ll want to turn this option off if you also intend to rename the column in the database.)
The Refactor menu also offers a couple of other time-saving utilities. One that we’re going to find really handy is Convert to Manual Implementation. This is useful when you want to customise the implementation of a property, for example by adding your own business logic or validation in the setter. Convert to Manual Implementation marks the property to be excluded from code generation in future, and copies the existing generated property code to a partial class to provide you with a starting point that you can then edit to meet your requirements. It even copies attributes such as column name mappings and validation attributes.
Finally, Create Partial Class quickly creates a partial class declaration for you, and Extract Interface allows you to rapidly declare an interface containing selected properties of an entity. (Extract Interface is available only in C# projects.)
One small caveat. Most of these refactorings need access to the generated code, and the code is only generated when you save the .lsmodel file. So if you try to refactor a model with unsaved changes, the designer will do its best, but you may get an error if refactoring needs to access one of those unsaved changes. (Some refactorings may also fail if you’re using a sufficiently radical custom template.)
We’d love to hear your feedback on these refactoring features and whether there are any other similar refactorings you’d like to see in LightSpeed. You can get the latest nightly of the free Express edition here, or retail editions from the store.
You should join our newsletter! Sent monthly:
Domain model refactoring in the LightSpeed designer…
Thank you for submitting this cool story – Trackback from DotNetShoutout…
If it can fail because it’s unsaved, why not save it? It seems like the more sensible thing to do :)
It’s like when you hit compile button–files get automatically saved too.
I can’t remember *grin*. I think the main reason for not wanting to force a save was because Visual Studio validates the model each time it is saved, and this can result in UI which (a) would be confusing when the user hadn’t initiated a save operation and (b) could result in the save being cancelled (in which case should we proceed with the refactor or not?). Also I felt in most cases it wouldn’t be necessary to save: so instead of performing an unrequested save “just in case,” I thought it would be better to go ahead, and only bug the user to save the file if it did actually run into problems. On reflection, though, the second argument is kinda weak (saving is normally cheap) and I think we can work around the first, so I’ll maybe take another look at this…
[...] it. And by now there’s lots of code that uses this wrong name. Too much effort to change it? Not with the LightSpeed Refactor command! Just right-click the offending property, choose Refactor > Rename, and watch the new name being [...]
Leave a Reply