This post originated from an RSS feed registered with .NET Buzz by Raymond Lewallen. Original Post: Class designer is leaving something to be desired - data persistence. Feed Title: Raymond Lewallen Feed URL: /error.htm?aspxerrorpath=/blogs/raymond.lewallen/rss.aspx Feed Description: Patterns and Practices, OOP, .Net and Sql Latest .NET Buzz Posts Latest .NET Buzz Posts by Raymond Lewallen Latest Posts From Raymond Lewallen

I’m sure most .Net developers have played around with the class designer some at this point.  Its a great tool for visualizing class structures, interfaces, implementations and relationships, as well as creating new classes.  Personally, I’m still a “type it out” kind of person.  I guess I’m just a masochist in that way, but I enjoy it.

Here’s what the class designer looks like, for those of you who are behind the times:

But here’s the beef I have with it.  No disconnected persistence model.  That also just happens to be the same issue I have always had with the Sql Server diagramming tool.  In my opinion, the class designer is not really a designer, its more of a real-time implementor.  If you make changes to the class designer view, its going to make changes to your actual code in your project.

I would much rather have a true designer that lets me play around with the classes and interfaces, try a couple of different ideas and patterns as I rumble through the logic in my head, and then later commit those changes to the actual project.  It also would more easily allow for 3rd party vendors to create some cool tools to use the same persisted data on disk to do some cool things with the model as well.  I could take the persisted data file and pass it on to somebody else to create a project from the model.  As it stands now, the designer has a direct relationship with the actual code, making on the fly changes.

Again, same issue with the Sql Server Diagramming tool.  No way to persist the data to disk.

So what we are left with now if you want to keep an external designer model to play with and implement later, is 2 different projects.  But committing changes from the designer project to your actual project that has your “real” code in it is no easy task either (made easier with source safe merge tools and other 3rd party compare/merge tools however).  You can play around with the model, but then when you’re done, you’ll have to get those changes over to a different project where you are actually creating your application.

I’ve had this conversation with some other people, who all agree a persistence model, whether XML, binary or even (although limiting) a proprietary persitence model would be very, very useful.  I’m hoping this is something they are looking at seriously with the next version (Orcas) of Visual Studio as an improvement to the class designer tool.  Would be nice to see the same type of implementation with the Sql Server diagramming tool, making it more of a true “designer” tool instead.