views:

88

answers:

2

Using LINQ to SQL make application development faster but dissolves the logical layers in the application. The data access layer and the business objects layers almost have no identity, they sit in the same dll. Does any one has an idea on how to develop an enterprise level application using LINQ to SQL. How do we cleanly separate the business object and the LINQ generated entities ? How would they communicate, how would data be transferred between our business objects and LINQ entities. Any article or any suggestions towards this would be greatly appreciate. Thanks.

+2  A: 

We're using L2S for our next generation of software that manages our plant operations and related applications. This is for a $2.5B thin film solar company. We have built a clearly defined L2S based n-tier application framework.

We also created our own code generator to generate an application set of entities, a L2S set of entities, a business logic layer and data access layer. The L2S set of entities is for back-end use only. The application entities (which have no L2S plumbing built in) is for transferring data back and forth from application to server. We use WCF for application tier to server tier communication.

Our applications use WCF to call to the back-end businss logic layer for data processing. The business logic layer calls to our data access layer for low level Linq based data access. Our application entities get passed to and from our back-end. In the back-end, we have very efficient mapping that maps an application entity to each L2S entity.

Works very well for us.

Randy

Randy Minder
A: 

You can get very far with L2S (as StackOverflow has proven), but IMHO Linq2SQL is not well suited (nor intended, I think) for "enterprise level applications".

Now that Entity Framework 4.0 has been released, you may want to consider going with EF instead. It supports POCO and will allow you do have a much nicer layered architecture.

Check out:

The ADO.NET Entity Framework

ADO.NET C# POCO Entity Generator

I recently ported a substantial code base from L2S to EF 4.0. Since EF now supports lazy-loading, you can have a very smooth transition from L2S to EF, leveraging the advanced features of EF only when you need them.

Rune