Should I use one LINQ DataContext or many?

Question

For a large project, would it make sense to have one datacontext that displays your database, with which you can interact with your classes?

Or it would be wiser to split this into small data files that will focus on the specific tasks in the database that will be needed.

I'm curious as to performance. I understand that the datacontext itself is a very lightweight object that only initializes its internal collections as they are required, etc. Therefore, when dealing with informational text with many corrections, but only two data tables should be as fast as with a special datacontext only in these two tables.

I also think that you will win during JIT, since the first class to access the data will compile your dc, which is now available for all classes.

Answer 1

I assume that you are asking about design and execution pattern. I would generally say no:

While you can split your database into several data contexts, then it would be desirable if and only if there was zero overlap between the two contexts.

Overlap is bad

eg. you have WebsiteContext and AdminContext . WebsiteContext designed to display Product and fulfill Order s. A WebsiteUser attaches to Order . AdminContext intended for your Staff members to process refunds for canceled Orders , which also link to WebsiteUser . AdminContext also needs to reset passwords and update other data for WebsiteUser .

You think about it because you do not want the website to process or even know about Returns

 WebsiteContext Product -- Order -- WebsiteUser AdminContext Staff -- Returns -- Order -- WebsiteUser 

In the above example, we see that we duplicate many objects in different data contexts. This smells bad, and it actually indicates that artificially dividing the database into different data contexts is the wrong solution. Do you have> 2 databases in the end or only one? Duplication violates the DRY (Dont Repeat Yourself) principle, because WebsiteContext.WebsiteUser is not the same as AdminContext.WebsiteUser, and in all likelihood the code will be messy when something has to take care which one they refer to them.

---

The Linq data context is just an OR mapper, and should be considered a bizarre black box that makes it easy to write a data access code. Some linq demos show that you no longer need other layers, but a program of any complexity still uses a multi-level design.

You are probably better off treating Linq objects as objects to easily transfer data and create a domain layer that hides them as an implementation detail. Read the DDD-Domain Driven Design.

By itself, using Linq objects from the user interface most closely resembles the Transaction Script template. In this case, you still get a logical level that will take care of the details.

---

Although you do not want the responsibility for the context to be so broad, the data context is simply a representation of the database. This is not a security mechanism, and it cannot stop you from corrupting data.

Answer 2

From the corner of the “repository template”, we can say that there are separate aggregates and minimization of navigation properties between aggregates. I'm not 100% sure that something although ... at the moment I am considering using a moderate-sized dbml using several repositories (the user interface does not use datacontexts directly - only the repository classes), and the navigation properties are marked as internal, so the DAL can use them ... Maybe .. .