JH-##### I have a code layer that, given a connection string, generates stored procedures for the base CRUD actions on a database as well as RUD actions for unique/foreign keys. It then gens a fully SqlParamater(ized), subclassed, ICloneable SqlCommand object for each one. As it creates them it stuffs them in a synchronized hashtable and either hands it back (WinFrom app) or stuffs it in the Application object (ASP.Net).
TT-$$$$$ Never talk about a performance penalty for me again :-) The hashtable for every attribute is a killer. We dont work with this. Basically our data store is an array of type object, and all properties know their data index in this array :-) Thats hardcoded in the generated proeprty code, regenerated on every startup. I think of allowing automatically generated SP's on a later stage, too, but SQL Server 2003 will propably allow us to go the other way and get rid of SQL for CRUD operations. Also note that things get more complicated with subtypes dynamically determined by data. One thing you dont do, btw., is handling object identity, as it looks like :-) JH 20021015 - I could have phrased that better -- I'm not storing the attributes/parameters in the hashtable, but rather the loaded (parameterized) SqlCommand objects. Basically, you pass the generator a connection string and the application object and it creates the stored procedures and associated SqlCommand objects, shoves them all in a hastable and lodges it in the application object. You get then get served up deep clones of them as required by your app. =================================== JH-##### I appreciate both those comments, but in general I like the way XML Schema generally keeps everyone honest and then there is the Web Services/WSDL angle that start adding some gravity to gen'ing the XSD's as well. TT-$$$$$ Both wrong. Now, for the XML schema - the EntityBroker supports dumping it's schema set down into an XML file.. It is more a debugging tool for me (and other developers), because basically it allows me what the EntitiyBroker sees. I dont really like that users otthe objects are able to change this. Also, finally, the web services are something I DONT EVER WANT to be entagled with my business object layer. Web services are for external application attachments ONLY - thats their design. JH 20021015 - Here we'll just have to disagree - I think we just view the utility of XML Schema somewhat differently which is fine. I'm not suggesting any spooky entanglement of the O-R and Web Services so much as if both are XSD-based the is the opportunity for some synergies. =================================== JH-##### Jeremy's cut at an O-R mapping layer is pattern-based to the hilt and fully Ambler-ized. It is well worth the read to anyone going down this road - can't recommend it enough. His also has "lazy-lookahead" child instancing and he generally gets right to the heart of the impedance mismatch. TT-$$$$$ I dont think that he has anything to tell me - sorry, dont want to sound high nosed here. But in the last two years I have propably read everything besides his thing on the web, including scott ambler's site. So I dont think I can stand more basics here :-) I consider myself to be one of the people who made this work :-) JH 20021015 - I also consider you one of the people who made this work as well. And while I know you won't be "challenged" by anything in Jeremy's case study and work at Dell, that's not the same as assuming it's all "basics" or not having anything to offer. JH 20021015 - To be honest, I find the the whole O-R problem space more a pain in the ass I'd rather not be bothering with than an overwhelming technical challenge (BizRule implementation is the interesting problem to me). But what I do find fascinating is all the varied and creative approaches folks have taken in developing their solutions. JH 20021015 - Yours, Jeremy's, Objectspaces, Deklarit, Visible, Alphora, Pragmatizer, ObjectMatter, Alachisoft, NTier, Olymar, LLBLGen, NSystemData, etc. are all interesting attacks on the problem. Are any of them perfect - not from my perspective, but collectively they represent a great response to what should have been a base functionality in .Net along with a standalone MS Rules.Net engine. Your solution and implementation looks to be one of the more thoughtful and robust, but so far I've found something interesting in all of them. JH 20021015 - The main thing I've learned, however, is I don't want jump in late in the game and rewrite what all of you have sweated over adding my own quirks thank you - I'll buy one of yours, you've earned it... You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
