views:

20

answers:

2

I've implemented the repository pattern on the data access layer of our current service layer.

We have an object model where the same class "historical notes" is mapped on mutiple objects (currently 6 but soon to be more!)

Part of the best practices for the use of linq to sql is not to have one dbml file for every table in the db, but instead to break it down, this way it doesn't have a huge performance hit when the context is created.

Unfortunately the logical places to separate the objects leaves the historical notes in 5 different DBML files. When the linq generator creates the classes it generates a different class in the different namespace.

I have a historical note object in the domain model, but I don't want to re-map the domain object model into the data model for every time we use the historical notes.

One of the things I don't want to do is break the "reading" of the data into multiple queries.

Is there a way I can map the historical note into multiple data models but only write the mapping once?

Thanks

Pete

Solution

Thanks for the help, I think I'm going to move back to one data context for all the data tables.

The work arounds involved in setting up the multiple models isn't worth the extra complexity and potential fragility of the code. Having to write the same left hand, right hand code to map the historical notes is all too much work and too many places to keep the code in sync.

Thanks guys for the input

+1  A: 

Part of the best practices for the use of linq to sql is not to have one dbml file for every table in the db, but instead to break it down, this way it doesn't have a huge performance hit when the context is created.

Where did you hear that? I don't agree. The DataContext is generally a fairly lightweight object, regardless of the number of tables.

See here for an analysis of the issues involving multiple data contexts:

LINQ to SQL: Single Data Context or Multiple Data Contexts?
http://craftycodeblog.com/2010/07/19/linq-to-sql-single-data-context-or-multiple/

In my opinion, you should have one datacontext per database. This would also solve your mapping problems.

See also http://stackoverflow.com/questions/337763/linq-to-sql-multiple-single-dbml-per-project

Robert Harvey
I read it in various blogs, the only one I still have a link to is this one http://www.sidarok.com/web/blog/content/2008/05/02/10-tips-to-improve-your-linq-to-sql-application-performance.html
Peter
Thanks for the links and your answer Robert I'm looking through them right now.
Peter
Hi, Peter. I looked at the blog entry you linked, and I agree with all of it except the part about multiple data contexts. The data context *does not* represent a single unit of work. That role belongs to your repository objects, not the DBML.
Robert Harvey
It is possible you might get a tiny performance improvement by splitting your DBML's (measured in milliseconds, not seconds), but the additional headaches are not worth it, IMO.
Robert Harvey
jeroenh
@jeroenh: Unfortunately Linq to SQL does not do this well. If you need a genuine unit-of-work abstraction you're better off creating a service layer, and sticking with a single DBML.
Robert Harvey
To get the multiple db contexts to work (in wcf) i had to create a "sessionprovider" class which had each of the DB contexts marked as [ThreadStatic] and then to instantiate a transaction I had to force all of the db contexts to use the same sql connection, otherwise the MSDTC tried to take over and that causes huge headaches on any machine that isn't Win server 2008. So in short I have already had a lot of issues to work around the multiple db contexts and none of them have been "pretty" for want of a better phrase, they get the job done but not in a manner i'm happy with.
Peter
Thanks for the help, I think I'm going to move back to one data context for all the data tables.The work arounds involved in setting up the multiple models isn't worth the extra complexity and potential fragility of the code. Having to write the same left hand, right hand code to map the historical notes is all too much work and too many places to keep the code in sync.Thanks guys
Peter
A: 

One option could be to put the historical notes in their own datacontext, and keep the relationships between this object and the rest of your model as 'ids' (so just foreign keys in the db). That's how I would do it anyway.

jeroenh
This is the work around I thought of too however this would force me to write code that loads the main object, then do a second load for the notes which would force the loss of the ability to say load with and have linq do all of this work for me.
Peter

related questions