So to understand you correctly, you have your own custom tool to help modify the code generated by the XSD to class generator? I thought about replacing or not using this tool because it didn't do everything I wanted. What do you mean by maintaining metadata in the schema, using your own namespaces? Do you create separate namespace with classes or structures that define the mapping? I was thinking of somehow extending the idea of the XSD to include mapping info. I think this is something MS should have thought about. How many enterprise dabases have coherent namings?
I am unsure if taking the time to create custom tools is good use of time at the moment. However, I would like to embark on developing a set of open source tools and utilities for .Net in the future. The Java world has such a rich sets of tools. I have found many frustrating problems with VS.Net. I anxiously look forward to fixes in version 2.0. Or is MS a version 3 company? -Loc >>> Jason Kaczor <[EMAIL PROTECTED]> 06/03/02 09:21AM >>> On Thu, 30 May 2002 12:44:28 -0700, Loc Nguyen <[EMAIL PROTECTED]> wrote: >board about this subject, I think it may be more trouble. It sounds like >the code generation is very troublesome. Someone was asking how to insert >logic into the generated code without it being overwritten, and he never >got a definitive answer. I also looked at what it took to do this and the Well, it is and it isn't. I simply generate initially using the XSD Schema designer. Then "divorce" the associated code file by a copy/rename, run my custom insert tools on the code-file, and voila... Our project tools simply regen the whole damn thing everytime we change the schema. >fact that you have to create an XSD file to generate the code from and >then maintain it troubles me. In my experience, whenever you have to >maintain some metadata somewhere, it quickly gets out of sync. It usually I maintain metadata in the schema, using my own namespaces. Works like a charm. Next we will be working on an extension/custom schema editor to make things easier for the team. Rule #1 about generated code. Never treat it as truly editable, when you want to make a change, make the change to the metadata source, then "re- gen", and if the generated code isn't what you need, write tools to do the touch-up's for you (simple open the schema.xsd in a generic dataset to quickly access it's metadata). >happens after the original developers have rolled off and new developers >are assigned to maintain it. Also, my requirements are a little Maintain the metadata, and re-gen. Personally, the maintainers are going to do a better job of maintaining a 1000-line gen tool, than a 28,000-line generated strongly-typed DataSet (one of ours is that large.) >different. I want to create business object that were mapped to my >datastore but with different column names. After skimming through some >books, I didn't see how to do this with the strongly typed dataset. I maintain the original table/view/stored proc and column names in my schema via my own custom namespaces. VS.NET leave's 'em alone, and my tools then gen the necessary data mapping. (Important to us, as we have VASTLY different database naming conventions, and we are using a dynamic relation/master database design to handle versioning.) The last thing I suggest, is not using inheritence, but use interfaces instead. You can use some inheritence/shadows in the interfaces, but your generator tools then become more complex. So, I have several XSD schema files, one being a base, next inherits from that, etc. I have to maintain the chain in each file via the custom namespace metadata (pretty simple), and then my generator will shoot out the appropriate interfaces. Code Generation by tightly-focussed tools is one of the most powerful project enablers I have ever seen. Heck, I have not yet performed the metrics, but in this project I'm guessing we have about 150,000 lines of generated code, but less than 20k lines of manually written code. It's allowing us the meet and exceed our published deadlines, with a tiny team and an "un-godly" set of requirements. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
