Is there any possibility to make update in the database by using LINQ only without using LINQ to SQL? If yes, please provide an example.
What is different between LINQ and LINQ to SQL?
No, "Just" LINQ (LINQ-to-Objects) won't update anything.
So to update a database you need either LINQ-to-SQL or LINQ-to-Entities (Entity Framework).
But you will need something like that to read from the database too, so there should be no problem.
LINQ is just framework support for powerful data querying in the .NET language. For any support, you need a LINQ provider. Some providers:
LINQ to Objects -> Using LINQ to query in memory collections
LINQ to SQL -> Light weight data query provider for SQL Server.
LINQ to Entities -> ORM for querying multiple databases.
LINQ to XML -> or XLINQ for querying XML
Related
it bit confusing, i'm reading these articles regarding linq to sql in mvc but are these links are alternative of each other ? mean one is telling to use LINQ to SQL and other something else ?
Creating Model Classes with LINQ to SQL?
and
Displaying a Table of Database Data?
First one uses Linq to SQL
Second uses Entity Framework. But it's also mentioned:
In this tutorial, we use the Microsoft Entity Framework. However, it is important to understand that you can use a variety of different technologies to interact with a database from an ASP.NET MVC application including LINQ to SQL, NHibernate, or ADO.NET.
So, there're variety of technologies you can use. It's up to you and your needs. That's it.
The second link is using EntityFramework; however, EF is only an ORM. Both examples are using LINQ to SQL.
In the EF example, MoviesDBEntities instance is not accurately represented by its reference name, entities. The object being instantiated is technically called a context (database, in this example). entities.MovieSet is an implementation of IQueryable, which supports LINQ extensions--specifically ToList(), which is the LINQ extension method being used in the EntityFramework example. Calling ToList() will cause the IQueryable instance to execute a corresponding SQL query, returning an object of type List<MovieSet>.
Is LINQ an ORM ?
I've heard a lot of people say LINQ follows the rules of an Object Relation Mapper. But I don't understand; is this true?
LINQ is a C#/VB.NET language syntax and a set of method signatures for querying data.
There are many providers for this syntax and some of them are ORMs. The simplest case is when you are querying collections in memory which is not an ORM. There are also ways to query XML, Active Directory and many others which are not ORMs using the same syntax and the same set of methods (implemented differently).
Practically every serious .NET ORM technology has some level of LINQ support
LINQ to SQL is the first ORM to support LINQ and it was kind of a proof of concept. It is easy to learn and lightweight but lacks a lot of features. It is still pretty decent and Stack Overflow used it (I'm not sure if they still use it).
Entity Framework has LINQ to Entities provider and it is the heavy hitter from Microsoft.
NHibernate has a LINQ provider that in my opinion barely works but they may fix it some day
There are more ORMs out there and most of them have some level of LINQ support.
Ok people, repeat after me:
LINQ is NOT about working with databases.
LINQ is an abstraction layer for working with data which allows for set based operations, projections, filters, etc on anything that can be enumerated over. It just happens to have providers for working with relational data (LINQ to SQL, LINQ to Datasets, LINQ to Entities).
Is the LINQ ORM ?
No. Linq is not itself an ORM.
This code uses Linq to Objects, which is still valid Linq:
var someData = new int[] { 5, 3, 2, 7, 4 };
var someResults = someData
.OrderByDescending(i => i)
.Take(3)
;
And here is some Linq to XML code:
IEnumerable<XElement> partNos =
from item in purchaseOrder.Descendants("Item")
where (int) item.Element("Quantity") *
(decimal) item.Element("USPrice") > 100
orderby (string)item.Element("PartNumber")
select item;
Neither of these code samples have anything to do with Object Relational Mapping, since they don't map objects, nor do they work with relational databases.
Linq has been used with some ORM technologies though:
Linq to Entities allows you to access the Entity Framework ORM with Linq.
Linq to NHibernate does the same for NHibernate.
You can find out how Linq itself works by checking out this library and the associated articles. They deal with Linq to Objects, but will give you the basis of how Linq itself works:
http://code.google.com/p/edulinq/
It will show you that Linq need not have anything to do with an ORM.
If we were to go by the wiki defiinition of the term Object-Relational Mapping,
Object-relational mapping (ORM, O/RM, and O/R mapping) in computer software is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to create their own ORM tools.
http://en.wikipedia.org/wiki/Object-relational_mapping
then yes, LINQ is an ORM in the sense that it is a programming technique for converting(and querying) data between incompatible systems in object-oriented programming languages, creating, in effect, a "virtual object database" that can be used from within the programming language.
LINQ is Language Intergrated Query and is NOT an ORM.
It can be used as query layer on top of an ORM product like Entity Framework or Telerik Open Access or NHibernate.
ORM is as you say Object Relation Mapper - it does mapping between entities in the database layer to entities into your Object Oriented code - classes that represent the database in your application.
For further discussion see this question.
I have an SQL query with joins. I want to use Linq. some one suggested me to avoid joins and use Linq include. How can I combine entities using Linq include? Is there a better way than joins ?
Thanks
LINQ to SQL converts LINQ syntax to an SQL query. If the query requires a Join, then LINQ to SQL will actually execute an SQL query with joins against the database. The advantage you may gain is that the LINQ to SQL query may be more optimized than the one you have written.
If you are not familiar with using LINQ and you have a working application, you will probably not gain anything other than complication by adding an additional layer of abstraction (LINQ). That being said, LINQ is an excellent and powerful tool. However, that doesn't change the truth to the adage "If it ain't broke don't fix it."
Basically, what you are considering is converting your application's data access procedure from
app -> SQL Query with Joins -> data objects
to
app -> LINQ Query with Joins -> SQL Query with Joins -> data objects
I am pretty well versed in both, and I think writing LINQ queries is a lot easier than writing SQL queries. (You get strongly typed models and Intellisense). However, if you only know SQL, then writing an SQL query is significantly easier than learning LINQ and writing a LINQ query .
Note that LINQ also supports joins. Here is an article on using joins in LINQ: http://odetocode.com/Blogs/scott/archive/2008/03/25/inner-outer-lets-all-join-together-with-linq.aspx .
I saw some code were linq was used on a traversing a dictionary object in c#. I thought linq was just for linq to sql for databases. The linq used in the code mentioned was a select type statement, just no database.
Is there linq without linq to sql for databases? Is that "linq" without the "sql" here to stay? I ask that because people talk about the entity framework replacing linq to sql but certainly the EF is not replacing linq that is used the fashion I described is it? Can you use the ef on a dictionary object? Hoping for comments. Thanks.
Heres where I saw it:
How to find duplicate pairs in a Dictionary?
Linq is a .NET framework based technology to query objects (anything that implements IEnumerable). Linq to SQL is an extension to that, that allows you to query SQL Server databases.
Yes, Linq, without the SQL, is here to stay. It is a fabulous technology. One of the best things, IMO, to come out of Redmond, in a long time.
LINQ stands for "Language Integrated Query" and is more than just a way to query SQL databases:
http://msdn.microsoft.com/en-us/library/bb397926.aspx
From the link above:
LINQ introduces standard, easily-learned patterns for querying and updating data, and the technology can be extended to support potentially any kind of data store.
LINQ is used all over the .NET framework now, and, as you mentioned in your question, is available to use against the native generic collection types. For me, this has completely changed how I write code:
List<int> myIntList = new List<int>();
.... populate with some data
myFilteredIntList = myIntList.Where(i => i > 10);
In addition to LINQ to SQL, there is LINQ to Objects, LINQ to XML, and LINQ to ADO.net.
Microsoft has been heavily investing in the LINQ feature set and it is here to stay... that being said, LINQ-to-SQL looks like it will be eventually retired in favor of LINQ to ADO.Net (Also known as Linq to Entities):
http://blogs.msdn.com/b/adonet/archive/2008/10/29/update-on-linq-to-sql-and-linq-to-entities-roadmap.aspx
LINQ itself is mostly just a pattern which is supported by language extensions such as query expressions. The implementation working on List<T> etc is usually known as LINQ to Objects; LINQ to SQL and LINQ to EF are implementations for databases via IQueryable<T>. Reactive Extensions provides an implementation over IObservable<T> and IQbservable<T>. Parallel Extensions provides an implementation for parallel processing over ParallelQuery<T>. They're all just working with the pattern supported by the language - methods such as Where and Select with appropriate parameters which can be created from lambda expressions.
Note that LINQ to XML is a bit of an oddity here - it's not a LINQ provider itself; it's just an XML API which works particularly well with LINQ to Objects.
That is sometimes called "LINQ to Objects," but, yes, the LINQ framework itself is here to stay, and the basis of both LINQ-to-SQL and LINQ-to-Entities/Entity Framework.
LINQ works by implementing extension methods on IEnumerable<T> and IQueryable<T>. Everything that implements IEnumerable<T> (i.e. all generic collections [with conversions available for non-generic collections]) can be used as the source for a LINQ query.
In the spirit of
All about LINQ
Current LINQ providers:
LINQ to Objects.
LINQ to SQL.
LINQ to XML.
LINQ to Entities.
LINQ to WMI.
LINQ to LDAP.
LINQ to Internet.
LINQ to Dataset.
LINQ to nHibernate.
So, what is after LINQ?
Does there any data source LINQ not cable of querying it?
[Edit]
From Adam Robinson's answer:
What sort of data source (if any) doesn't lend itself toward a formal query definition?
This isn't after Linq as such, but it's probably after Linq as you currently think about it acting as a pull mechanism on a sequence.
The new .NET 4.0 IObservable<T> and IObserver<T> interfaces (a.k.a. the Rx framework) extend Linq's capabilities to allow a push mechanism and simpler construction of event driven asynchronous workflows. There's plenty more about it if you follow the other posts on the blog I linked to.
So Linq wasn't capable of querying events. But now it is!
You're forgetting LINQ-to-Datasets, et al. However, the question isn't so much about whether or not LINQ is capable of querying a particular data source, since exposing something to LINQ (in a provider-specific way instead of falling back on LINQ-to-objects) just relies on interface implementation. The real question would be what sort of data source (if any) doesn't lend itself toward a formal query definition.
LINQ to WMI
LINQ to LDAP
LINQ to Internet - query the Internet
(from Google)
Linq to nHibernate has also just been completed
You asked:
What sort of data source (if any)
doesn't lend itself toward a formal
query definition?
Linq is a provider so as long as the data source has a way of querying it then it should be possible to create a Linq provider for it. In my mind if you have a data source you also have a "formal query definition" or can create one. If not, is it really a data source or just of blob?