Linq2Sql Best Practices

Question

I'm recently migrating to Linq2Sql and all my future projects will be using Linq2Sql. Having said that, I researched a lot on how to properly plug-in Linq2Sql in application design.

• what to put at what layer ?
• How do you design your repositories and business layer services ?
• Should I use DTOs over Linq2Sql entities on interaction layer ?
• what things should I be careful about ?
• what problems did you face ?

I did not find any rock-solid material that really talked about one single thing and everyone have their own opinions. I'm looking forward to your ideas on how to integrate/use Linq2Sql in projects. My priority is maintenance[it should be maintenable and when multiple people work on same project] and scalabilty [it should have scope of evolution].

Thanks.

Answer 1

Hey curious geek,

I have been using linq to entities for the last two and half years on production applications and I can say it has been a really nice experience... but that doesn’t means you should do everything with Linq.

I am going to try to give you some answers to your questions,

I think you should ask first what kind of application you want to create; once the scenario is clear you will have an odd idea of number of transactions or queries you are going to perform against the database (or repository).

Linq could be extremely useful to abstract data access, context and entities handling, but everything comes with at a cost. Objects will be created with a cost and you really need to think about this.

If your application has a ‘nice-not-too-heavy’ data access Linq will be the perfect tool to save time for your application.

If your application is entirely based on data extraction or processing, Linq will be great as well.

If your application is handling huge blocks of data (check your application) you will need to do something else to avoid creating a bunch of objects that might be useless.

What does that means? You need to know what a smart data access means... and that is leave SQL to work for you (in the case of SQL); if you are going to do lots of joints, cross information and stuff, create stored procedures that creates the data result for you and then get it using Linq or SqlCommand or SqlDataAdapters, etc...

What to put at what layer? Since Linq gives you the data access abstraction you can pretty much place your code where the business logic demands it. There are tons of good practices of how to structure your code; Linq (as any other entity framework or data access libraries) will fit in the right spot. Avoid whenever is possible direct linq expression in your controls (asp.net has lots of controls with linq data sources), instead wrapped your ‘query’ with a service class that can be instantiated by your code or controls as an object data source.

What have I found? Pure Linq is not always possible on big applications or projects (so you will end up with many things in linq and some in previous more simple solutions to access your repositories) but will help you to save time. Implementing stored procedures is a MUST if you want to deliver great quality applications.

Hope this comment helps. Cheers.