The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Concerning the future of LINQ to SQL

I just spent months switching apps over to LINQ to SQL and after a recent post here I see that LINQ to SQL may or may not have a future. Entity framework is either replacing it or absorbing it. Honestly, I can't figure out what's really going on with all the marketing babble and a very low signal to noise ratio on the subject. Many complaints of the EF being less useful or even useless. My head is swimming over this.

Quite frankly, I really like LINQ to SQL. It's quick and easy to implement and it just makes sense to me. It also dramatically shrinks the number of lines of code just about anywhere I use it.

What's my next logical step? This whole ordeal makes me not trust microsoft all over again. Should I just go with a third party solution that actually has a clear plan and future vision? Am I concerned about nothing? I haven't looked into EF yet so I don't know how difficult it is to rewrite LINQ to SQL into EF.

Just because a new option becomes available doesn't mean what you're doing now will stop working. There's no reason to rewrite any of your code.

My main concern is the time invested studying and coding what could be a dead technology and how it was touted by microsoft as a must-use technology only to be chucked in the ash can for something which is quite possibly (personally, I don't know) less useful. My current working code isn't being rewritten but future implementations will be, if necessary.

I'm just looking for a more reliable map to follow to get me where I want to go.

This is the world us developers live in. Everything is changing all the time. My favorite PHP framework changed database abstraction layers this year, and looks like they're favoring a whole new ORM for next year. I don't use the same ORM I used 4 years ago when programming in Java either.

EF is very similar to Linq 2 Sql. Just has a lot more features. So not much would change. Also has .dbml's, etc. Linq is basically still in use in EF, but now allows you to use linq against any databasae. MySql, oracle, etc (From what I understand)

MS was going to drop Linq 2 Sql in favour of EF as its a lot more powerfull. But a lot of people started complaining about this decision as EF would just not be feasible on a small project, where linq would be usefull.

So MS decided to carry on developing on linq 2 sql. I also heard that EF will be built into VS 2010.

And if MS do stop developing linq, that will be fine, u can still use it. They just would not advance it, but it already works quite well, so if it had to be dropped, u could carry on using it without problems.

Its like MS dropping XP in favour of Vista. Doesnt mean that XP stops working.

So, essentially LINQ to SQL is dead. That's a shame. However, before you jump on the mess that is Entity Framework, let me try and push you towards NHibernate!

NHibernate is a far better choice of ORM that EF for a number of reasons:

Domain-Centric Development
NHibernate helps move away from the data-centric development that MS pushes, removing the database as the key component of your application and putting the emphisis on your domain, where is belongs! This leads to a far richer domain model that is easier to maintain amd avoids vendor lockin (see Persistence Ignorance)

Mature
NHibernate is far more mature than EF, and has been used (so far) in far more projects.

Persistence Ignorance
This is a biggie, and not something you will see pushed by MS by choice. This essentially means your domain (Customer.cs, etc.) are ignorant of how they ae persisted. What does this mean? Well, if NHibernate dies, you can easily change your persistence framework without changing your domain. It also means you are not locked into an RDBMS vendor. We test locally with Sqlite, and run in production with Sql Server, but you could just as easily run on MySql in production with no change to any of your code

FluentNHibernate
Gone are the days of XML mapping! FluentNHibernate delivers a friction free mapping experience, even making it possible to mapp your domain completly automatically

Proper Lazy Loading & other advanced ORM concepts.
Out of the box, EF doesn't support lazy loading, even L2S did but that pales in comparison to what NHib can do.

EF is very similar to Linq 2 Sql. Just has a lot more features. So not much would change. Also has .dbml's, etc. Linq is basically still in use in EF, but now allows you to use linq against any databasae. MySql, oracle, etc (From what I understand)

MS was going to drop Linq 2 Sql in favour of EF as its a lot more powerfull. But a lot of people started complaining about this decision as EF would just not be feasible on a small project, where linq would be usefull.

So MS decided to carry on developing on linq 2 sql. I also heard that EF will be built into VS 2010.

And if MS do stop developing linq, that will be fine, u can still use it. They just would not advance it, but it already works quite well, so if it had to be dropped, u could carry on using it without problems.

Its like MS dropping XP in favour of Vista. Doesnt mean that XP stops working.

So it's not a big of a deal as many are making it out to be? That's plenty good news.

Originally Posted by dhtmlgod

So, essentially LINQ to SQL is dead. That's a shame. However, before you jump on the mess that is Entity Framework, let me try and push you towards NHibernate! ... There are many many many more awesome reasons to pick NHib. Check it out, you won't be disappointed

I've seen you push NHibernate for quite some time and just didn't have the time to look into it. Now I'm forced to. Where do I start? I'm looking at the "Getting Started Guide" now. Regardless, it seems like a step backwards for me in that it doesn't make sense in the way that LINQ to SQL does but that is most likely due to the fact that I've just spent so much time learning this way of doing things.

Your main issue is probably going to be session management. I use Castle's NHibernate facility to automagically do this for me, but I think this might introduce some unnecessary complexity just now ( Castle should be the next thing you look into ).

Below is a basic implementation and an example of how to use it, let me know if you have any questions: