Mmm... interesting question... :-D So I'm even more persuaded that external XML based mappings are the way we should work by default.
AND we should improve the linq to sql external mappings, for example in two ways: 1. Allowing xinclude or another way to split the mapping in different xmls 2. Extending the xsd to add DbLinq features, like the ability to add custom converters for example which I'd find very useful (and AFAIK NHibernat support a similar concept) That said, you are right. But, for attribute based mappings, it should be simple to add a static cache (don't blame me, Jon! :-D) to the AttributeMappingSource class to share the mappings between datacontext. AFAIK, such mapping can not change without a recompilation (and the application restart) so that chache could be a "simple" _thread_safe_ static Dictionary<Type, MetaModel> where the Type would be the DataContext.GetType() result. (I'm not sure about the MetaModel, but you should get the point) Giacomo On Wed, Jun 17, 2009 at 2:54 PM, Andrus Moor <[email protected]> wrote: > > > > First becouse the member has no state by itself, and the constructor have > nothing to do with it (AFAIK) > > > > DataContext() constructor loops over all of its members and over all its > tables properties to get attibutes to create metadata. > If you set breakpoint to FindTables() in AttributeMappingSourc() you can > see that FindTables() is called from DataContext constructor every time if > DataContext is instantiated. > > Andrus. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DbLinq" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/dblinq?hl=en -~----------~----~----~----~------~----~------~--~---
