Thomas, my response is also inline (marked #####)... While I get the drift of you code, the abstraction of the data layer appears to be fairly wedded to the CMS architecture.
*** No, the opposite is true :-) See, the only reasons why I only choose examples from the CMS is because that was code I was currently working on. I have other systems here that use the Broker, too. The CMS is wedded to the broker, not the other way around. Again, I just wanted to give samples out of a "coherent suprrounding", otherwise I could have choosen our address management system, our accounting system in development or our license management system :-) #### [I'm new to this list and have now just found your earlier postings and your site so I have a better feel for it all now.] I have seen several other "Attribute-based" object mapping layers and my take on them in general is they look to have a some overhead and place some burden on developers from a design-time/coding perspective and possibly incur a performance hit as well. These attribute approaches [appropriately] place the emphasis on the developers designing objects with the mapping code gen'ing/resync'ing with the database when they're done. How transparent is all this for developers? Having gone down that road further than most, could you comment on those aspects of using an "Attribute-based" O-R mapping approach, particularly resyncing the DB after changes to objects, prospects for hooks/templates for tools like Visio Architecture, XDE, etc... 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). *** I have decided to go against SP's FOR NOW (means: the sql mapping layer is free to generate and use them, but my current one does not). The perforamance benefit is not yet big enough :-) ##### Given it's all generated code, I'll grant you it matters little where the generated code resides at this point, though I believe the performance benefits can accrue in a large [hierarchal] implementation to the point where SP's can make a difference, but again, at this point that's an optimization issue and not a big deal to me. My next natural step is an O-R mapping layer in lieu of seeing MS Objectspaces anytime soon. I've looked at a dozen .Net O-R Mapping layer products/projects/archtectures now and have done initial prototypes with both your approach and the DataSet-centric approach Ben has taken. I definitely agree MS dropped the ball here and I wish they would just get on with Objectspaces and spare us all the hassle. *** ObjectSpaces will come with V2 of the framework. Still, IMHO, our product will be superior then, becaue I plan to move the way of fully integrating with SQL Server YUKON, while MS propably goes the "generic" way. ##### I hope Yukon is the reason we haven't seen Objectspaces yet and that it will be released concurrently and fully integrated with Yukon. Kind of pointless if it isn't given it would be the prime vehicle for .Net/Yukon integration. Or maybe they'll scrap it all together and do other form of XML/XSD-base serialization to Yukon. Hopefully all .Net servers will employ the same O-R mapping technology; in fact, I'd prefer they take even longer to ensure they do. I tend be fairly agnostic other than having a desire to have the entire layer driven off an XSD repository (an DLL version of XSD would be handy...). That said, for less complex requirements I simply embed a DataRow in objects and for the collection object use an embedded DataSet. *** I thought about using an external file, but then I found out two things: (a) You cant change most of your mapping info anyway. For strings, our mapping layer handles SOME of the database functionality ,like makign a dhar field "fixed length" by padding with spaces etc. (b) as a programmer I prefer to have everything in one place. *** We later will go even further. The generated schema (and generated classes) will be compilable into a dll. And a schema syncrhonisation tool will be able to genereate the ddatabase model from the embedded schema :-) ##### 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. You seem to have been fairly thorough and thoughtful in your developing your architecture (I particularly like the Condition object [if one is going to use in-line SQL statements]). Your's general tack reminds me of Jeremy Miller's approach (http://www.csharptoday.com/content.asp?id=1770). *** Hm, I dont read csharptoday, so I cant read this. But I was basiclly following scott ambler :-) ##### 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. Are you commercializing this? If not do you have any more detail you can share (an article perhaps), or if you are, perhaps a white paper on the general architecture. *** it will be commercial soon :-) Not expensive, though, and with a free for noncommercial license. ##### Good! Then possibly we'll see an article or white paper on the architecture sometime soon -- [ not so subtle hint ;-) ]. Thomas, it sounds great and I look forward to getting a better look at it. Joseph You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
