|
Language Integrated Query(LINQ)
|
|
1. What is LINQ? DLINQ? XLINQ?
|
|
LINQ stands for "Language Integrated Query". It is a set of features such as lambdas,
extension methods, and query comprehensions that enable compilers to understand
and implement query logic over in-memory collections of objects. For more information
about lambdas, extension methods, and query comprehensions, please refer to http://msdn.microsoft.com/netframework/future/linq
and the LINQ Project Overview document at http://msdn.microsoft.com/library/en-us/dndotnet/html/linqprojectovw.asp.
|
|
2. Isn't LINQ a Microsoft-only technology? Isn't DLINQ only for SQL Server?
|
|
LINQ is extensible by creating extension methods against your own types. Specifically
with DLINQ, we are actively working on ways to enable database vendors to more easily
hook their products into the query translation pipeline.
|
|
3. What languages have announced plans to support LINQ?
|
|
Microsoft languages, c#, Vb.net, VC++ with CLR, J#, Sql Server 2005/2008, etc
|
|
4. Can I use LINQ with databases other than SQL Server?
|
|
Yes. DLinq, the database implementation of LINQ, uses ADO.NET for its database connectivity,
so in theory, DLinq applications can connect to any database that uses a .NET Data
Provider. As you might expect, however, the prerelease code works best with SQL
Server 2005. Support for other databases should be available when the product ships.
|
|
5.Will there be a tool to help create the database-object mappings used by DLinq
applications
|
|
Yes. LINQ ships with a command-line tool currently named SqlMetal that can automatically
generate DLinq database-to-object mappings, automating the process of creating object
mappings for your database objects. Although Microsoft might change the name of
this tool when the product is shipped, the company intends the tool to be part of
the shipping LINQ release
|
|
6. How do I get default values from the database when inserting new entities?
|
|
LINQ to SQL does not support using default values from the database. The values
in the entity at the time SubmitChanges is called are used instead. You can override
how LINQ to SQL inserts entities by implementing an insert method on the DataContext.
For an entity type called ‘Entity’ implement a function with the signature of ‘InsertEntity(Entity
instance).
|
|
7. How do I attach and update entities? When I attach and call SubmitChanges nothing
happens.
|
|
Attaching entities to a DataContext may not work as you intend. An attached entity
is merely the equivalent of an entity that has just been queried from the database
and not yet modified. In order to instruct the DataContext that you intend to have
the entity updated you must provide it with information describing how the entity
has changed. You can do this in a variety of ways. 1) You can call Attach to add
the entity to the DataContext and then modify individual properties. This assumes
the entity is not already in a modified state. 2) You can call the form of Attach
that takes both a current and original instance of the entity. The DataContext will
recognize that individual properties values differ. 3) You can call the form of
Attach that takes an additional Boolean parameter set to true to indicate that the
DataContext should treat the entity as all properties modified. The option requires
that the object have a version property.
|
|
8. How do I serialize entities using .Net Remoting?
|
|
LINQ to SQL does not support serialization using .Net Remoting. Key data types such
as EntityRef and EntitySet are not serializable.
|
|
9. How do I serialize entities using WCF (Windows Communication Foundation)?
|
|
LINQ to SQL supports serialization as XML via WCF by generating WCF serialization
attributes and special serialization specific logic during code-generation. You
can turn on this feature in the designer by setting serialization mode to ‘Unidirectional’.
Note this is not a general solution for serialization as unidirectional mode may
be insufficient for many use cases.
|
|
10. How do I move entities between tiers in my multi-tier application?
|
|
While it is possible to use WCF serialization to move entities between tiers it
may be insufficient for your application as it will not allow for round-tripping
of changes. Defining a custom data exchange contract as part of your web service
API is a better all around solution.
|
|
11. Should I create a new DataContext in every business logic method?
|
|
The DataContext conforms to the Unit of Work design pattern. Unless you are moving
data between physical tiers between each operation you should keep your DataContext
alive for the duration of work.
|
|
12. Should I keep my DataContext in a static/global/shared variable?
|
|
The DataContext is not thread safe and is not meant to be shared. A DataContext
is meant to be used for a single unit or work or at most for multiple consecutive
units of work.
|
|
13. Where should I put my business logic? The system I’m currently developing uses
static methods on the entities themselves for loading, saving and other operations?
|
|
The DataContext conforms to the Unit of Work design pattern. A work context must
exist and be maintained separate from the entities themselves. You should either
place all your business logic as methods on the DataContext or devise a separate
business context that encapsulates a DataContext instance. You should not be using
static methods.
|
|
14. Are LINQ to SQL entities Business Entities or Data Transfer Objects? How do
I build a business layer on top of LINQ to SQL?
|
|
LINQ to SQL entities are both business entities and data transfer objects. LINQ
to SQL takes the place of your Data Access Layer and is the basis for your Business
Layer. You can add business logic directly to the DataContext or encapsulate the
DataContext in your own business context. The purpose for making a separate business
context would be to restrict access to other DataContext methods. If this is not
an issue for you, putting all business logic methods on the DataContext is the best
choice.
|
|
15. How can I keep entities cached beyond the lifetime of a single DataContext?
I want to keep a collection of entities in a cache so that all subsequent requests
can read from this cache instead of going back to the database each time?
|
|
It is possible to cache entities beyond the lifetime of a single DataContext. However,
it is dangerous to do this for entities with defer loaded properties as you are
likely to get accesses back to the originating DataContext if these properties are
ever navigated. You are also likely to unintentionally retain all entities materialized
via that same DataContext causing what may appear to be a memory leak. To alleviate
these problems you can either turn deferred loading off when first retrieving these
entities or you can dispose the DataContext after the entities are fully loaded
using an operation such as ToList or ToArray.
|
|
16. How can I re-attach an entity to a new DataContext? When I try to do this I
get an exception thrown?
|
|
LINQ to SQL does not support re-attaching entities. Entities are never actually
detached from their originating DataContexts. The Attach methods are intended to
be used with entity instances that are newly created after round-tripping data from
another physical tier. LINQ to SQL detects that an entity belongs to another DataContext
if any deferred properties are still unloaded. It is possible to trick the DataContext
into accepting entities from another DataContext by either not having deferred properties,
pre-loading all of them or turning deferred loading off on the originating DataContext.
|
|
17. How can I use globally cached entities to initialize the association properties
of a new entity instance or to change an association property in order make an update?
When I try this I get strange behaviors like inserts I did not intend or exceptions
thrown during SubmitChanges?
|
|
LINQ to SQL does not support mixing and matching entities loaded from different
DataContext instances together in the same object graph. Trying to do so is generally
a bad idea. Most association properties are bi-directional, so assigning one to
a property of another or adding one to a collection property changes state and references
in both entities. This means that globally cached entities are being modified potentially
on multiple threads at the same time (when running as a service). As a general rule
of thumb, a single connected entity graph should only be associated to a single
unit of work at a time. Instead of using globally cached entities to assign association
properties, use entities retrieved from the DataContext you are using to perform
the insert or update, or assign values to the foreign key fields directly to avoid
extra round-trips to the database server.
|