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.
Related
Just wanted to know if NHibernate 3 have full linq support yet ?
Thanks.
There is no such thing as "full" LINQ support.
LINQ to anything except Objects is a leaky abstraction. Some operations that are trivial to express in an object model are hard to translate to SQL, and vice-versa.
That said, the LINQ provider in NH3 is quite usable, and a lot of work is being put into it (a lot of that will be visible in the 3.0.1 release, which will be out around 28/Feb/2011)
The good news is with NH you always have alternatives. If you can't do a particular query with LINQ, there's always HQL, Criteria, QueryOver and even SQL. They all integrate nicely with the rest of the stack.
No there are still some unsupported features. It's not a full LINQ implementation.
It doesn't have full linq support because it is too much (impossible much) work to write a full link provider. I don't think any full linq provider exists.
You can find the currently unsupported features in Jira.
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 am using SQL Server 2005 in a project. I have to decide about datalayer. I would like to use LINQ in my project. I saw SubSonic 3 supporting LINQ and I also have option for LINQ to SQL, because i can have typed lists from LINQ to SQL.
I am wondering what is different between LINQ to SQL and Subsoinc 3 LINQ, Which is beneficial?
Thanks!
JAMIL
In case you haven't read this already, the Subsonic site has a pretty lengthy overview of some differences between LinqToSql and Subsonic (and NHibernate).
http://subsonicproject.com/docs/Comparisons
Outside of specific differences of the technologies, you may also want to consider the implications of going with an open-source 3rd party tool vs an official Microsoft product. There are pros and cons to each! ;)
although NHibernatebe greater ORM than Linq2SQL, NHibernate Linq is very very limited.
If the idea is to use LINQ, choose Linq2SQL, because Subsonic also have several limitations.
If you remove LINQ from equation, then NHibernate will be the best solution, but only for complex and bigger applications.
For small ones, uses Subsonic or even Linq2SQL
LinqToSql has many very significant downsides and it's almost never the right solution.
SubSonic 3 has many of the benefits of LinqToSql with few of the downsides.
If you must choose between these two, SubSonic is a very clear winner.
In the end, NHibernate is significantly better than both and for most projects it is clearly the best way to go.
That said, you can go a long way with SubSonic and it is a good product. You just need to be aware that there are limitations and places it won't go that NHibernate will go.
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?
As someone who hasn't used either technology on real-world projects I wonder if anyone knows how these two complement each other and how much their functionalities overlap?
LINQ to SQL forces you to use the table-per-class pattern. The benefits of using this pattern are that it's quick and easy to implement and it takes very little effort to get your domain running based on an existing database structure. For simple applications, this is perfectly acceptable (and oftentimes even preferable), but for more complex applications devs will often suggest using a domain driven design pattern instead (which is what NHibernate facilitates).
The problem with the table-per-class pattern is that your database structure has a direct influence over your domain design. For instance, let's say you have a Customers table with the following columns to hold a customer's primary address information:
StreetAddress
City
State
Zip
Now, let's say you want to add columns for the customer's mailing address as well so you add in the following columns to the Customers table:
MailingStreetAddress
MailingCity
MailingState
MailingZip
Using LINQ to SQL, the Customer object in your domain would now have properties for each of these eight columns. But if you were following a domain driven design pattern, you would probably have created an Address class and had your Customer class hold two Address properties, one for the mailing address and one for their current address.
That's a simple example, but it demonstrates how the table-per-class pattern can lead to a somewhat smelly domain. In the end, it's up to you. Again, for simple apps that just need basic CRUD (create, read, update, delete) functionality, LINQ to SQL is ideal because of simplicity. But personally I like using NHibernate because it facilitates a cleaner domain.
Edit: #lomaxx - Yes, the example I used was simplistic and could have been optimized to work well with LINQ to SQL. I wanted to keep it as basic as possible to drive home the point. The point remains though that there are several scenarios where having your database structure determine your domain structure would be a bad idea, or at least lead to suboptimal OO design.
Two points that have been missed so far:
LINQ to SQL does not work with Oracle
or any database apart from SqlServer. However 3rd parties do offer better support for Oracle, e.g. devArt's dotConnect, DbLinq, Mindscape's LightSpeed and ALinq. (I do not have any personal experience with these)
Linq to NHibernate lets you used
Linq with a Nhiberate, so it may
remove a reason not to use.
Also the new fluent interface to Nhibernate seems to make it less painful to configure Nhibernate’s mapping. (Removing one of the pain points of Nhibernate)
Update
Linq to Nhiberate is better in Nhiberate v3 that is now in alpha. Looks like Nhiberate v3 may ship towards the end of this year.
The Entity Frame Work as of .net 4 is also starting to look like a real option.
#Kevin: I think the problem with the example you are presenting is that you are using a poor database design. I would have thought you'd create a customer table and an address table and normalized the tables. If you do that you can definately use Linq To SQL for the scenario you're suggesting. Scott Guthrie has a great series of posts on using Linq To SQL which I would strongly suggest you check out.
I don't think you could say Linq and NHibernate complement each other as that would imply that they could be used together, and whilst this is possible, you're much better off choosing one and sticking to it.
NHibernate allows you to map your database tables to your domain objects in a highly flexible way. It also allows you to use HBL to query the database.
Linq to SQL also allows you to map your domain objects to the database however it use the Linq query syntax to query the database
The main difference here is that the Linq query syntax is checked at compile time by the compiler to ensure your queries are valid.
Some things to be aware of with linq is that it's only available in .net 3.x and is only supported in VS2008. NHibernate is available in 2.0 and 3.x as well as VS2005.
Some things to be aware of with NHibernate is that it does not generate your domain objects, nor does it generate the mapping files. You need to do this manually. Linq can
do this automatically for you.
Fluent NHibernate can generate your mapping files based on simple conventions. No XML-writing and strongly typed.
I've recently worked on a project, where we needed to change from Linq To SQL to NHibernate for performance reasons. Especially L2S's way of materializing the objects seems slower than NHibernate's ditto and the change management is quite slow too. And it can be hard to turn the change management off for specific scenarios where it is not needed.
If you are going to use your entities disconnected from the DataContext - in WCF scenarios for example - you're may have a lot of trouble connecting them to the DataContext again for updating the changes. I have had no problems with that with NHibernate.
The thing I will miss from L2S is mostly the code generation that keeps relations up-to-date on both ends of the entities. But I guess there are some tools for NHibernate to do that out there too...
Can you clarify what you mean by "LINQ"?
LINQ isn't an data access technology, it's just a language feature which supports querying as a native construct. It can query any object model which supports specific interfaces (e.g. IQueryable).
Many people refer to LINQ To SQL as LINQ, but that's not at all correct. Microsoft has just released LINQ To Entities with .NET 3.5 SP1. Additionally, NHibernate has a LINQ interface, so you could use LINQ and NHibernate to get at your data.
By LINQ, I'm assuming you mean LINQ to SQL because LINQ, by itself, has no database "goings on" associated with it. It's just an query language that has a boat-load of syntac sugar to make it look SQL-ish.
In the very basic of basic examples, NHibernate and LINQ to SQL seem to both be solving the same problem. Once you get pass that you soon realize that NHibernate has support for a lot of features that allow you to create truly rich domain models. There is also a LINQ to NHibernate project that allows you to use LINQ to query NHibernate in much the same way as you would use LINQ to SQL.
First let´s separate two different things:
Database modeling is concerned about the data while object modeling is concerned about entities and relationships.
Linq-to-SQL advantage is to quickly generate classes out of database schema so that they can be used as active record objects (see active record design pattern definition).
NHibernate advantage is to allow flexibility between your object modeling and database modeling. Database can be modeled to best reflect your data taking in consideration performance for instance. While your object modeling will best reflect the elements of the business rule using an approach such as Domain-Driven-Design. (see Kevin Pang comment)
With legacy databases with poor modeling and/or naming conventions then Linq-to-SQL will reflect this unwanted structures and names to your classes. However NHibernate can hide this mess with data mappers.
In greenfield projects where databases have good naming and low complexity, Linq-to-SQL can be good choice.
However you can use Fluent NHibernate with auto-mappings for this same purpose with mapping as convention. In this case you don´t worry about any data mappers with XML or C# and let NHibernate to generate the database schema from your entities based on a convention that you can customize.
On the other hand learning curve of Linq-to-SQL is smaller then NHibernate.
Or you could use the Castle ActiveRecords project. I've been using that for a short time to ramp up some new code for a legacy project. It uses NHibernate and works on the active record pattern (surprising given its name I know). I haven't tried, but I assume that once you've used it, if you feel the need to drop to NHibernate support directly, it wouldn't be too much to do so for part or all of your project.
As you written "for a person who have not used either of the them"
LINQ to SQL is easy to use so any one can use it easily
It also support procedures, which helps most of the time.
Suppose you want to get data from more than one table then write a procedure and drag that procedure to designer and it will create everything for you,
Suppose your procedure name is "CUSTOMER_ORDER_LINEITEM" which fetch record from all these three table then just write
MyDataContext db = new MyDataContext();
List<CUSTOMER_ORDER_LINEITEMResult> records = db.CUSTOMER_ORDER_LINEITEM(pram1, param2 ...).ToList<CUSTOMER_ORDER_LINEITEMResult>();
you can use you records object in foreach loop as well, which is not supported by NHibernate