LINQ to SQL

Functionality Improvements in the New Version of LinqConnect

Monday, March 26th, 2012

Devart is glad to announce a beta version of completely reworked LinqConnect ORM with better performance and large number of improvements.

New 4.0 version of LinqConnect marks a new milestone in LinqConnect development. Renewed LinqConnect demonstrates a new degree of performance and stability. Now it can be used in most complicated use cases and supports submit of very complex object graphs.

Starting from the 4.0 version, LinqConnect uses only its own classes. It does not reference the System.Data.Linq assembly any more, and this assembly is not loaded with your applications, using LinqConnect. However you don’t need to worry about LINQ to SQL compatibility. Public interface of our classes is completely compatible with the public interface of Microsoft LINQ to SQL classes. Moreover, we provide the Upgrade Wizard for easy upgrading of your LinqConnect projects to the new version of LinqConnect in a few clicks.

Cache Improvements

Now LinqConnect cache has two different modes. The first mode, classical, is recommended to use it when DataContext is used as a Unit of Work and is a short-lived object (Microsoft recommends to use LINQ to SQL DataContext in this way). In this mode DataContext uses hard links on all the entity objects and they are released when the DataContext itself is released.

The second, self-clearing mode is intended for applications when DataContext is considered as a long-lived object, not as a Unit of Work. In this mode, weak references to entity classes are used. When you don’t use an object any more, it is deleted from the cache and is not tracked any more. However this mode requires more memory and resources for tracking.

Submit Functionality

In the 4.0 version we redesigned the Submit functionality. The main improvements are the optimizations of tracking and submitting of the complex object graphs with the parent-child relation chains.

Submitting objects with many-to-many associations was also improved. Now it requires a smaller number of database calls. There is no database call when adding/deleting an object to/from a collection. When deleting an entity with an associated collection, one delete operation is performed for the associated table.

Delete rule behaviour was changed. Now this operation is executed by the database. LinqConnect removes the affected objects from cache after this operation.

Stored Procedure Mapping Improvements

New version of LinqConnect allows you to map stored procedure OUT parameters that return cursors to enumerable parameters of the corresponding DataContext method. Now you don’t need to mess with the ResultType attribute and ImultipleResult when working with stored procedures, returning cursors in Oracle and PostgreSQL.

Query Compilation Improvements

Query compilation algorithm was completely reworked to implement using of ILGenerator. Now the compilation is performed much faster and requires less RAM.

Materialization Improvements

In the new LinqConnect version we have optimized entity materialization algorithms greatly. Materialization of entities with associated entities is now 1,5 times faster, and materialization of entities, returned by stored procedures, is 4 times faster.

Compiled Query Cache Improvements

Now compiled queries and materialization functions are stored separately in the cache. This increases performance when executing different queries returning results of the same type.

Download LinqConnect and try our improvements now!

Working with Large Models and Oracle Autoincrement Fields in New Version of Entity Developer

Thursday, March 24th, 2011

Starting from version 3.20, Entity Developer provides you with additional features to simplify working with models. Now you can split your model into diagrams to improve its readability. Entity Developer automatically generates a sequence and a trigger for autoincrement fields in Oracle when generating the database script from the model or when synchronizing the database with a model. We constantly work on improving Entity Developer and now we are focusing on performance increase and usability enhancement. The following enhancements have been added in the latest version:

(more…)

Table-per-Type vs Table-per-Hierarchy Inheritance

Monday, December 27th, 2010

In this article we will compare the performance of both most used inheritance types – Table-per-Hierarchy (TPH) and Table-per-Type (TPT), supported by LinqConnect starting from version 2.00. For a better understanding of these inheritance types, we will use the Model First approach when the object model is developed first and after that the database scheme is generated.

To develop an object model, the Entity Developer tool will be used.

Our tests are performed on the following object model:

We have a hierarchy of three entity classes: the base class Gadget and its descendants – MobilePhone and Netbook.
(more…)

LinqConnect and ORMBattle.NET

Friday, August 13th, 2010

ORMBattle.NET has recently updated their results of testing various .NET Framework ORMs and added LinqConnect to their lists. LinqConnect demonstrates one of the best results it their tests.

ORMBattle.NET is an open-source project for ORM comparison, supported by a development team from X-tensive.com. This project contains a set of tests for feature-oriented comparison, but it is more focused on the performance tests (CRUD operation performance, object materialization, etc.).

LinqConnect development team agrees with most of the tests. The results on the whole are reliable enough to consider them when choosing ORM framework.

We already are studying the situations where LinqConnect showed bad results and working on performance improvement.

Working with transactions in Entity Framework and LINQ to SQL

Monday, February 1st, 2010

Entity Framework

In this article we consider a short description of the Entity Framework and LINQ to SQL transactional models. There are also some simple code listings illustrating different aspects of the transactional model.

A transaction is a series of operations performed as a single unit of work. Entity Framework transactions are a part of its internal architecture. The SaveChanges method operates within a transaction and saves results of the work. It is designed to ensure data integrity. The common reason of integrity problems is a Concurrency violation, which can be raised during the saving process. Concurrency violation occurs an OptimisticConcurrencyException in this case. To resolve this conflict you have to call the Refresh method with the StoreWins or ClientWins value, and after that call SaveChanges again. But be aware, that the Refresh with the ClientWins option can be a source of problem too. It rewrites all changes made to the data after context query execution.
(more…)


dotConnect Team Blog