Question

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

Was it helpful?

Solution

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 LINQ to SQL: Multiple / Single .dbml per project?

OTHER TIPS

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.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top