LINQ to DB is the fastest LINQ database access library offering a simple, light, fast, and type-safe layer between your POCO objects and your database.
Architecturally it is one step above micro-ORMs like Dapper, Massive, or PetaPoco, in that you work with LINQ expressions, not with magic strings, while maintaining a thin abstraction layer between your code and the database. Your queries are checked by the C# compiler and allow for easy refactoring.
However, it's not as heavy as LINQ to SQL or Entity Framework. There is no change-tracking, so you have to manage that yourself, but on the positive side you get more control and faster access to your data.
In other words LINQ to DB is type-safe SQL.
linq2db is a .NET Foundation project.
Development version nuget feed (how to use)
- Rich Querying API:
- Explicit Join Syntax (In addition to standard LINQ join syntax.)
- CTE Support
- Bulk Copy/Insert
- Window/Analytic Functions
- Merge API
- Extensibility:
Visit our blog and see Github.io documentation for more details.
Code examples and demos can be found here or in tests.
Release Notes page.
- linq2db.EntityFrameworkCore (adds support for linq2db functionality in EF.Core projects)
- linq2db.AspNet (adds support for linq2db configuration within ASP.NET Core applications)
- LINQPad Driver
- DB2 iSeries Provider
- ASP.NET CORE 2 Template
- ASP.NET CORE 3 Template
- ASP.NET CORE 3 Template with Angular
Notable open-source users:
- nopCommerce (starting from v4.30) - popular open-source e-commerce solution
- OdataToEntity - library to create OData service from database context
- SunEngine - site, blog and forum engine
Unmantained projects:
- LinqToDB.Identity - ASP.NET Core Identity provider using linq2db
- IdentityServer4.LinqToDB - IdentityServer4 persistence layer using linq2db
No, this is not the donate link. We do need something really more valuable - your time. If you really want to help us please read this post.
From NuGet:
Install-Package linq2db
In your web.config
or app.config
make sure you have a connection string (check this file for supported providers):
<connectionStrings>
<add name="Northwind"
connectionString = "Server=.\;Database=Northwind;Trusted_Connection=True;Enlist=False;"
providerName = "SqlServer" />
</connectionStrings>
.Net Core does not support System.Configuration
so to configure connection strings you should implement ILinqToDBSettings
, for example:
public class ConnectionStringSettings : IConnectionStringSettings
{
public string ConnectionString { get; set; }
public string Name { get; set; }
public string ProviderName { get; set; }
public bool IsGlobal => false;
}
public class MySettings : ILinqToDBSettings
{
public IEnumerable<IDataProviderSettings> DataProviders => Enumerable.Empty<IDataProviderSettings>();
public string DefaultConfiguration => "SqlServer";
public string DefaultDataProvider => "SqlServer";
public IEnumerable<IConnectionStringSettings> ConnectionStrings
{
get
{
yield return
new ConnectionStringSettings
{
Name = "Northwind",
ProviderName = "SqlServer",
ConnectionString = @"Server=.\;Database=Northwind;Trusted_Connection=True;Enlist=False;"
};
}
}
}
And later just set on program startup before the first query is done (Startup.cs for example):
DataConnection.DefaultSettings = new MySettings();
You can also use same for regular .NET.
Important: you also can generate those classes from your database using T4 templates. Demonstration video could be found here.
using System;
using LinqToDB.Mapping;
[Table(Name = "Products")]
public class Product
{
[PrimaryKey, Identity]
public int ProductID { get; set; }
[Column(Name = "ProductName"), NotNull]
public string Name { get; set; }
// ... other columns ...
}
At this point LINQ to DB doesn't know how to connect to our database or which POCOs go with what database. All this mapping is done through a DataConnection
class:
public class DbNorthwind : LinqToDB.Data.DataConnection
{
public DbNorthwind() : base("Northwind") { }
public ITable<Product> Product => GetTable<Product>();
public ITable<Category> Category => GetTable<Category>();
// ... other tables ...
}
We call the base constructor with the "Northwind" parameter. This parameter (called configuration name
) has to match the name="Northwind" we defined above in our connection string. We also have to register our Product
class we defined above to allow us to write LINQ queries.
And now let's get some data:
using LinqToDB;
using LinqToDB.Common;
public static List<Product> All()
{
using (var db = new DbNorthwind())
{
var query = from p in db.Product
where p.ProductID > 25
orderby p.Name descending
select p;
return query.ToList();
}
}
Make sure you always wrap your DataConnection
class (in our case DbNorthwind
) in a using
statement. This is required for proper resource management, like releasing the database connections back into the pool. More details
Most times we get the entire row from the database:
from p in db.Product
where p.ProductID == 5
select p;
However, sometimes getting all the fields is too wasteful so we want only certain fields, but still use our POCOs; something that is challenging for libraries that rely on object tracking, like LINQ to SQL.
from p in db.Product
orderby p.Name descending
select new Product
{
Name = p.Name
};
Rather than concatenating strings we can 'compose' LINQ expressions. In the example below the final SQL will be different if onlyActive
is true or false, or if searchFor
is not null.
public static List<Product> All(bool onlyActive, string searchFor)
{
using (var db = new DbNorthwind())
{
var products = from p in db.Product
select p;
if (onlyActive)
{
products = from p in products
where !p.Discontinued
select p;
}
if (searchFor != null)
{
products = from p in products
where p.Name.Contains(searchFor)
select p;
}
return products.ToList();
}
}
A lot of times we need to write code that returns only a subset of the entire dataset. We expand on the previous example to show what a product search function could look like.
Keep in mind that the code below will query the database twice. Once to find out the total number of records, something that is required by many paging controls, and once to return the actual data.
public static List<Product> Search(string searchFor, int currentPage, int pageSize, out int totalRecords)
{
using (var db = new DbNorthwind())
{
var products = from p in db.Product
select p;
if (searchFor != null)
{
products = from p in products
where p.Name.Contains(searchFor)
select p;
}
totalRecords = products.Count();
return products.Skip((currentPage - 1) * pageSize).Take(pageSize).ToList();
}
}
This assumes we added a Category
class, just like we did with the Product
class, defined all the fields, and registered it in our DbNorthwind
data access class. We can now write an INNER JOIN query like this:
from p in db.Product
join c in db.Category on p.CategoryID equals c.CategoryID
select new Product
{
Name = p.Name,
Category = c
};
and a LEFT JOIN query like this:
from p in db.Product
from c in db.Category.Where(q => q.CategoryID == p.CategoryID).DefaultIfEmpty()
select new Product
{
Name = p.Name,
Category = c
};
In the previous example we assign an entire Category
object to our product, but what if we want all the fields in our Product
class, but we don't want to specify every field by hand? Unfortunately, we cannot write this:
from p in db.Product
from c in db.Category.Where(q => q.CategoryID == p.CategoryID).DefaultIfEmpty()
select new Product(c);
The query above assumes the Product class has a constructor that takes in a Category object. The query above won't work, but we can work around that with the following query:
from p in db.Product
from c in db.Category.Where(q => q.CategoryID == p.CategoryID).DefaultIfEmpty()
select Product.Build(p, c);
For this to work, we need a function in the Product
class that looks like this:
public static Product Build(Product product, Category category)
{
if (product != null)
{
product.Category = category;
}
return product;
}
One caveat with this approach is that if you're using it with composed queries (see example above) the select Build part has to come only in the final select.
At some point we will need to add a new Product
to the database. One way would be to call the Insert
extension method found in the LinqToDB
namespace; so make sure you import that.
using LinqToDB;
using (var db = new DbNorthwind())
{
db.Insert(product);
}
This inserts all the columns from our Product class, but without retrieving the generated identity value. To do that we can use InsertWith*Identity
methods, like this:
using LinqToDB;
using (var db = new DbNorthwind())
{
product.ProductID = db.InsertWithInt32Identity(product);
}
There is also InsertOrReplace
that updates a database record if it was found by primary key or adds it otherwise.
If you need to insert only certain fields, or use values generated by the database, you could write:
using LinqToDB;
using (var db = new DbNorthwind())
{
db.Product
.Value(p => p.Name, product.Name)
.Value(p => p.UnitPrice, 10.2m)
.Value(p => p.Added, () => Sql.CurrentTimestamp)
.Insert();
}
Use of this method also allows us to build insert statements like this:
using LinqToDB;
using (var db = new DbNorthwind())
{
var statement = db.Product
.Value(p => p.Name, product.Name)
.Value(p => p.UnitPrice, 10.2m);
if (storeAdded) statement.Value(p => p.Added, () => Sql.CurrentTimestamp);
statement.Insert();
}
Updating records follows similar pattern to Insert. We have an extension method that updates all the columns in the database:
using LinqToDB;
using (var db = new DbNorthwind())
{
db.Update(product);
}
And we also have a lower level update mechanism:
using LinqToDB;
using (var db = new DbNorthwind())
{
db.Product
.Where(p => p.ProductID == product.ProductID)
.Set(p => p.Name, product.Name)
.Set(p => p.UnitPrice, product.UnitPrice)
.Update();
}
Similarly, we can break an update query into multiple pieces if needed:
using LinqToDB;
using (var db = new DbNorthwind())
{
var statement = db.Product
.Where(p => p.ProductID == product.ProductID)
.Set(p => p.Name, product.Name);
if (updatePrice) statement = statement.Set(p => p.UnitPrice, product.UnitPrice);
statement.Update();
}
You're not limited to updating a single record. For example, we could discontinue all the products that are no longer in stock:
using LinqToDB;
using (var db = new DbNorthwind())
{
db.Product
.Where(p => p.UnitsInStock == 0)
.Set(p => p.Discontinued, true)
.Update();
}
Similar to how you update records, you can also delete records:
using LinqToDB;
using (var db = new DbNorthwind())
{
db.Product
.Where(p => p.Discontinued)
.Delete();
}
Bulk copy feature supports the transfer of large amounts of data into a table from another data source. For faster data inserting DO NOT use a transaction. If you use a transaction an adhoc implementation of the bulk copy feature has been added in order to insert multiple lines at once. You get faster results then inserting lines one by one, but it's still slower than the database provider bulk copy. So, DO NOT use transactions whenever you can (Take care of unique constraints, primary keys, etc. since bulk copy ignores them at insertion).
using LinqToDB.Data;
[Table(Name = "ProductsTemp")]
public class ProductTemp
{
public int ProductID { get; set; }
[Column(Name = "ProductName"), NotNull]
public string Name { get; set; }
// ... other columns ...
}
list = List<ProductTemp>
using (var db = new DbNorthwind())
{
db.BulkCopy(list);
}
Using database transactions is easy. All you have to do is call BeginTransaction() on your DataConnection, run one or more queries, and then commit the changes by calling CommitTransaction(). If something happened and you need to roll back your changes you can either call RollbackTransaction() or throw an exception.
using (var db = new DbNorthwind())
{
db.BeginTransaction();
// ... select / insert / update / delete ...
if (somethingIsNotRight)
{
db.RollbackTransaction();
}
else
{
db.CommitTransaction();
}
}
Also, you can use .NET built-in TransactionScope class:
// don't forget that isolation level is serializable by default
using (var transaction = new TransactionScope())
// or for async code
// using (var transaction = new TransactionScope(TransactionScopeAsyncFlowOption.Enabled))
{
using (var db = new DbNorthwind())
{
...
}
transaction.Complete();
}
Here you can read about MERGE support.
Here you can read about Window (Analytic) Functions support.
If you would like to use MiniProfiler or other profiling tool that wraps ADO.NET provider classes, you need to configure our regular DataConnection to use wrapped connection.
// example of SQL Server-backed data connection with MiniProfiler enabled for debug builds
public class DbDataContext : DataConnection
{
// let's use profiler only for debug builds
#if !DEBUG
public DbDataContext() : base("Northwind")
{
// this is important part:
// here we tell linq2db how to access underlying ADO.NET classes of used provider
// if you don't configure those mappings, linq2db will be unable to use provider-specific functionality
// which could lead to loss or unavailability of some functionality when profiled connection enabled
MappingSchema.SetConvertExpression<ProfiledDbConnection, IDbConnection> (db => db.WrappedConnection);
MappingSchema.SetConvertExpression<ProfiledDbDataReader, IDataReader> (db => db.WrappedReader);
MappingSchema.SetConvertExpression<ProfiledDbTransaction, IDbTransaction>(db => db.WrappedTransaction);
MappingSchema.SetConvertExpression<ProfiledDbCommand, IDbCommand> (db => db.InternalCommand);
}
#else
public DbDataContext() : base(GetDataProvider(), GetConnection()) { }
private static IDataProvider GetDataProvider()
{
// create provider instance (SQL Server 2012 provider in our case)
return new SqlServerDataProvider("", SqlServerVersion.v2012);
}
private static IDbConnection GetConnection()
{
// create provider-specific connection instance. SqlConnection in our case
var dbConnection = new SqlConnection(@"Server=.\SQL;Database=Northwind;Trusted_Connection=True;Enlist=False;");
// wrap it by profiler's connection implementation
return new StackExchange.Profiling.Data.ProfiledDbConnection(dbConnection, MiniProfiler.Current);
}
#endif
}
Still have questions left? Check out our documentation site and FAQ