Is it wise to tie my framework to Linq to SQL?

Is it wise to tie my framework to Linq to SQL?

Old forum URL:

almostchristian posted on Saturday, November 13, 2010

I've been working on an extension to the CSLA framework that ties it with Linq to SQL in order to reduce code. 

My goal was to link the PropertyInfo with fetch and persist methods which will retrieve or store the property values when the object is saved or fetched . The base class has a Linq to SQL object as a type parameter so the fetch and persist lambdas in the overloaded RegisterProperty methods are strongly typed. Below, Customer is a Linq to SQL class.

public class CustomerEntry : LinqRootBusinessBase<CustomerEntry, Customer>

protected static readonly PropertyInfo<string> FirstNameProperty = RegisterProperty<string>(c => c.FirstName, r => r.FirstName, (c, r) => r.FirstName = c.FirstName);

In the data access portion of the code, you only need to implement two methods which defines the DataContext and the Linq query the fetch the row required. You don't need to load and save the values from Linq to SQL, it is already handled in the base class.


        protected override Customer FetchRow(MultiCriteria criteria, Table<Customer> table)        {

            return (from x in table

                    where x.CustomerID == (int)criteria["CustomerID"]

                    select x).Single();


        public override IDisposable GetConnectionToken()        {

            return SetDataContext<DataAccess.AdventureWorksDbDataContext>("AdventureWorksDB");


I've also created other base classes and I'm happy so far with the framework. My concern is that the classes are strongly tied to Linq to SQL, I don't know if I should attempt trying to make it work with entities and I think a separate version would be required. I don't have experience working on projects with Linq to SQL. Is it a ORM choice? I attempted to work with Entities but it doesn't play well with the schema I have to work with.


Maybe I should have stuck with code generation, but thats no fun Big Smile and I wouldn't learn as much. But I fear later on, I'll have a maintenance problem on my hands.

Ideas and advice would be greatly appreciated.


RockfordLhotka replied on Saturday, November 13, 2010

Microsoft has made it pretty clear that their direction is EF, not L2S. But since L2S shipped as part of .NET, it falls under the standard service agreement, which means they'll basically keep it running and support it for 10 years, but it probably won't get enhanced, or be integrated into anything new or that sort of thing.

almostchristian replied on Saturday, November 13, 2010

Hmmm. I'll look into entity in the future, but for now L2S works well and I don't need any of the features in entities. Hopefully, I could add entity support later on without breaking too much of my code. Designing frameworks is hard. Thanks Rocky.

Vinodonly replied on Sunday, November 14, 2010

hi almostchristian,

your approach looks very interesting.. is it possible for you to share more details/code on how this full thing is working..

almostchristian replied on Wednesday, November 17, 2010

Sure! I'd love to share my work. I let me prepare some samples and I'll share a link

almostchristian replied on Wednesday, November 17, 2010

You can download my code and a  sample using the AdventureWorks sample database here!1357

I got it working on Silverlight once but then I did something and it broke. Silverlight is not a priority for me right now so if someone can provide a working example, please do. I need suggestions and criticism so I can improve my code.

Vinodonly replied on Thursday, November 18, 2010

I liked the whole idea of elminating the codegens and overall this looks quite intersting.. although linq to sql fact is also undeniable..


in any case, thanks for sharing.. i will get back with my comments after studying code..

Copyright (c) Marimer LLC