LINQ multiple datacontexts?

greengumby posted on Tuesday, January 06, 2009

Just been reading a few blogs on best LINQ to SQL practices and would like to get some CSLA thoughts on this.

A method of using LINQ to SQL is to create a new DataContext for each of your Use Cases.

As the CSLA ContextManager GetManager() returns a datacontext that is based on the connectionstring/databasename wont this cause problems
should a child fetch/update refer to another datacontext. Im thinking the ContextManager will try and cast the datacontext as the incorrect type.

Maybe this scenario should never happen but Im new to this  :)

Thanks
Jeremy

 

 

 

 

 

ajj3085 replied on Wednesday, January 07, 2009

If you're using the same connection string or database name across all use cases, that would be a problem.  But if you use the database name route, you could have a connection string for each use case.  Of course I'm not sure that's very practice though.

I'm not sure about the value of having a DataContext per use case; I would think some use cases would end up using at least some of the same tables, and then if you change the schema of one of these tables you'll need to update multiple data contexts... not something I would think is very maintainable.

greengumby replied on Wednesday, January 07, 2009

ajj3085:

I'm not sure about the value of having a DataContext per use case; I would think some use cases would end up using at least some of the same tables, and then if you change the schema of one of these tables you'll need to update multiple data contexts... not something I would think is very maintainable.

I completely agree with you here :)

So how would you suggest on creating/designing the L2S dbml files ?

I don't think sticking all tables/views/sp in one DataContext is what MS had intended ;)

Cheers

 

 

ajj3085 replied on Thursday, January 08, 2009

What's wrong with having all views, tables and sps in one data context?  That's how I've been using L2S all along.  To me, the datacontext represents a database.. so it should provide access to all of those things.

greengumby replied on Thursday, January 08, 2009

Im developing a Web application and thought the overhead of instantiating/disposing a datacontext with  > 100 tables would of been resource intensive?

Maybe im wrong here I will try and get some time too create a little test.

 

ajj3085 replied on Friday, January 09, 2009

I don't see why it would impact performance.  The DataContext subclass won't have any fields, so there's nothing to initialize when it's new'ed up.  There would be the same overhead whether the DC has 1 table or 100, I would think.  I could be missing something, but looking at the code that's how it seems.. unless the DataContext does reflection it it's constructor... but that would be a horrid design.