LINQ to SQL implements data access Universal base class

LINQ to SQL is fascinating, and in. NET applications,. It provides a secure, powerful, and flexible way to perform data access, which is easy to read in the current Microsoft Evangelist Introduction.

Unfortunately, when you study LINQ carefully, I find it's not very easy to use LINQ in a multi-tier architecture.

This article describes the typical problem points for implementing a data tier with LINQ to SQL, and provides a simple, convenient, and flexible way to overcome them.

The following features are included in the Ling to SQL implementation data access generic class that accompanies this article:

Implements the repository pattern, and you can perform crud (Create, Update, Delete) operations of LINQ entity types in less than 10 lines of code.

seamlessly collaborate to support LINQ disconnect mode (Disconnected LINQ modes).

Enables transparent database updates and data loading between a single database and a LINQ entity.

Provided as a handy feature, when debugging your application, it outputs all executed SQL statements to the console.

This article assumes that you have a basic understanding of LINQ to SQL (also known as DLINQ) and how to use it. Otherwise,,, back to this page, take a look at the introductory series in this tutorial, how to use LINQ to SQL in a multi-level application.

The problems that exist

LINQ to SQL is too easy to use if you are just interfacing the database directly with the Linqtodatasource object on your UI layer. However, this approach is not entirely object-oriented, and certainly not a desirable architecture, unless you are intended for fast coding and messy applications and ultimately not to extend it.

Instead, most developers divide their applications into layers, as follows:

Data access Layer (database access Layer)

Business Layer (Business Layer)

User interface layer (UI Layer)

This is the so-called multi-tier database application design. LINQ to SQL is used for the data access layer.

The problem with Linqto SQL is-despite its many advantages-it is not easy to implement the data tier.

Consider the following database schema (db Schema):

Once you are loading and saving a LINQ entity to the same data context instance (which is called "Connection mode"), using LINQ to implement the data layer is straightforward. Instance

For example, let's get the customer with the entity number 1 from the database, change the property name "Homer" and then store it in the database again. In a multi-tier database application, code somewhere in the UI or business layer might look like this:

1.

2.　　　　　　 //create a new repository instance

3.　　　　　　 CustomersRepository customersRepository = new CustomersRepository();

4.　　　　　　 //load a customer instance and change it's FirstName;

5.　　　　　　 Customer customer = customersRepository.Load(2);

6.　　　　　　 customer.FirstName = "Homer";

7.　　　　　　 //commmit customer to database

8.　　　　　　 customersRepository.Save(customer);