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>.
Related
I have started to learn Linq recently, So I came across IQueryable and IEnumerable. I have understood the difference and where to use what. But I have a small doubt will IEnumerable and IQueryable have the same effect across all the databases let's say we have PostgreSQL and MongoDB will it have same effect on PostgreSql a relational DB and MongoDb a non-relational database? Could someone please help me with this? Any extra information is appreciated. Thanks in Advance.
The .NET drivers that allow you to use LINQ expressions against SQL and NO-SQL databases have their limitations.
For instance, in mongo's most popular driver for c# website (MongoDB C# Driver), we are recommended to use an analyser to tell us which LINQ expressions are valid or not:
However, and answering your other question, this is only valid for the IQueryable interface, because it is the only one among the two where your LINQ expressions will be translated into Mongo queries. For the IEnumerable interface, you're always safe, as the query will only take place in memory once the data is fetched from the database.
Remember that both IQueryable and IEnumerable support deferred execution. The difference is that with IEnumerable when you instanciate the list (.ToList) you'll be querying the database and ONLY THEN apply your filter (in memory). When you instanciate an IQueryable, it will 'apply' your filter in the database query itself (that's why it is faster and usually recommended when dealing with databases - you'll fetch potentially less data from the DB).
The differences between IQueryable and IEnumerable are very well described here: Returning IEnumerable vs. IQueryable
I have some confusion that, In Linq-to-Object we work in-memory data to execute LINQ query that is process by c# language.
When i write a Linq query that is execute base on in-memory data why we use provider (LINQ-to-Object)?
No, Linq to Object IS NOT A PROVIDER and it doesn't have to relay on any other intermediate provider to run query(linq to object).
To understand it more clearly, we have to understand what provider actually is. Provider is basically the implementation that implements IQueryProvider and IQueryable interface and this mainly translates your linq query to SOMETHING that your provider understands. For example, when you go for LINQ to SQL queries your queries converted/translated into SQL, its get translated into SQL because your provider (in this case) only understands SQL.
When you run query against In-Memory collection of data, C# don't have to translate your linq query to other query.
As #Stilgar mention "Providers are used when the source is IQueryable". When you are working against In-Memory data, your source is basically IEnumerable.
LINQ to Objects is not a LINQ provider. It is an implementation of the LINQ API on IEnumerable. The LINQ API can be implemented on practically any type as long as you name your methods properly and accept the proper arguments. That being said there is something very close to a LINQ provider related to LINQ to Objects. Providers are used when the source is IQueryable and the compiler produces an expression tree. An expression tree can be compiled to a delegate so the Compile method acts as something very similar to a LINQ provider.
Also note that in practice "LINQ Provider" is often used to indicate simply an implementation of the LINQ API. It is kind of similar to how "argument" and "parameter" are used interchangeably despite the small difference.
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 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.
I was just reading about Linq to SQL being discontinued. For a while I put off learning Linq at all. Even on asp.net, when I last checked, their data access tutorials were using table adapters and bll classes. Then there are linq tutorials. Now that I have read this and that the Entity Framework is the new way to go, does that mean all the Linq "stuff" I have been reading about for a year and a half, how great it is, etc., is all this just gone? No one ever seems to settle on the right way to do things or at least some standard way with MS products. And I understand that you can't say one way is right for everything. But, in this particular case I do not understand why there cannot be some settling on data access.
Or, is Linq To SQL just the ORM portion of Linq? What exactly would I learn now if I wanted to use an ORM? I have read several things on StackOverflow, but none that really help me know what to do.
It seems that nHibernate may be better than any of the Microsoft choices. Yes, I know there are others (subsonic, and others were mentioned in various SO questions.)
Thank you.
No.
LINQ to SQL is built on top of LINQ, which is one of the fundamental added language features in .NET 3.5 Framework.
Technically other ORMs can implement their own LINQ systems, e.g., NHibernate already has LINQ to NHibernate going. This is on top of the ones provided in the framework, such as LINQ to XML, LINQ to Objects etc.
The Entity Framework certainly doesn't mean that LINQ is going away - the Entity Framework is a LINQ provider itself!
LINQ is a whole collection of technologies, and more than that - it's a pattern which you can implement for your own data provider as well.
LINQ to SQL is just one example of that pattern. For what it's worth, I think LINQ to SQL is being de-emphasized rather than actually going away, but we'll see...
Personally I find LINQ to Objects the most useful LINQ provider in the first place :)
Linq to sql is just one of many linq providers out there (there is linq to db4o, linq to starcounter, linq to objects, linq to ado and many, many more). The entity framework has its own linq provider, called linq to enteties. Your year of reading about linq is not lost.
Linq is much more than Linq-to-SQL. Things like Linq-to-Objects and Linq-to-XML are part of the technology, for example.
I doubt they are going away! Fingers crossed. ;-)
LINQ hasn't gone away. LINQ to SQL hasn't either, but it is not Microsoft's strategic platform for data access, that would be Entity Framework. EF uses LINQ to Entities so if you've spent time learning about LINQ, it'll still be valid and useful.
LINQ isn't a product-specific technology, though. It is easy to leverage the power and flexibility in collections of (almost) all kinds. eg.
List<MyType> myList = new List<MyType>();
// populate the list here
var filteredResults = from o in myList
where o.property == "hello world"
select o;
is (conceptualy) valid, even if the code example here is flawed.
LINQ is a library for processing sequences of data. And it is pretty awesome.
These sequences of data may be anything that implements IEnumerable, or it may be whatever sequences are provided by adapters.
Linq to SQL is an adapter which allows a SQL database to provide sequences of data that are compatible with LINQ.
There is also a Linq to XML which is an adapter that lets you treat an XML document as a sequence of data, allowing LINQ to process it.
LINQ is just the query language, and it is extremely good at what it does. It has nothing to do with databases or SQL. It is definitely worth learning just to be able to process in-memory collections easily.