Home/ Questions/Q 983001
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T04:47:11+00:00

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

  • 0

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

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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?

    • 0