Concerning the future of LINQ to SQL

[imaginekitty]

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.

[Dan Grossman]

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.

[imaginekitty]

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.

[Dan Grossman]

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.

You just pick what seems most appropriate for the task at hand.

[NightStalker-DNS]

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.

Just my 2c on the matter. LOL

http://ayende.com/Blog/archive/2008/...nq-to-sql.aspx

[NightStalker-DNS]

Ok, found this "linq"(pun intended.LOL) that should clear it up:

http://blogs.msdn.com/adonet/archive...s-futures.aspx

[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!

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.

NH Profiler
http://nhprof.com/

There are many many many more awesome reasons to pick NHib. Check it out, you won't be disappointed

[imaginekitty]

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.

Just my 2c on the matter. LOL

http://ayende.com/Blog/archive/2008/...nq-to-sql.aspx

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

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.

[dhtmlgod]

woot!

Ok, check out the FluentNHibernate AutoMap Getting Started: http://wiki.fluentnhibernate.org/show/AutoMapping

Are you developing a Web app or desktop? If it's a web app, Mvc or WebForms?

[imaginekitty]

woot!

Ok, check out the FluentNHibernate AutoMap Getting Started: http://wiki.fluentnhibernate.org/show/AutoMapping

Are you developing a Web app or desktop? If it's a web app, Mvc or WebForms?

Web app now. Desktop app soon.

WebForms. I did look in to MVC recently but didn't have time to delve in.

[dhtmlgod]

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:

namespace Demo.DataAccess
{
    using System;
    using System.Collections.Generic;
    using System.Web;
    using FluentNHibernate.Cfg;
    using FluentNHibernate.Cfg.Db;
    using Invocas.Intranet.Domain.Security;
    using Invocas.Intranet.Repositories;
    using NHibernate;
    using NHibernate.Criterion;
 
    public interface ISessionBuilder
    {
        ISession GetSession();
    }
 
    public class HybridSessionBuilder : ISessionBuilder
    {
        private static ISessionFactory sessionFactory;
        private static ISession currentSession;
 
        public ISession GetSession()
        {
            ISessionFactory factory = GetSessionFactory();
            ISession session = GetExistingOrNewSession(factory);
            return session;
        }
 
        private ISessionFactory GetSessionFactory()
        {
            if (sessionFactory == null)
            {
                sessionFactory = Fluently.Configure()
                    .Database(MsSqlConfiguration
                                  .MsSql2005
                                  .ConnectionString(connstring => connstring.FromConnectionStringWithKey("connection string key")))
                    .Mappings(m =>
                              m.FluentMappings
                                  .AddFromAssemblyOf<User>())
                    .BuildSessionFactory();
            }
 
            return sessionFactory;
        }
 
        private ISession GetExistingOrNewSession(ISessionFactory factory)
        {
            if (HttpContext.Current != null)
            {
                ISession session = GetExistingWebSession();
                if (session == null)
                {
                    session = OpenSessionAndAddToContext(factory);
                }
                else if (!session.IsOpen)
                {
                    session = OpenSessionAndAddToContext(factory);
                }
 
                return session;
            }
 
            if (currentSession == null)
            {
                currentSession = factory.OpenSession();
            }
            else if (!currentSession.IsOpen)
            {
                currentSession = factory.OpenSession();
            }
 
            return currentSession;
        }
 
        public ISession GetExistingWebSession()
        {
            return HttpContext.Current.Items[GetType().FullName] as ISession;
        }
 
        private ISession OpenSessionAndAddToContext(ISessionFactory factory)
        {
            ISession session = factory.OpenSession();
            HttpContext.Current.Items.Remove(GetType().FullName);
            HttpContext.Current.Items.Add(GetType().FullName, session);
            return session;
        }
    }
 
    public class NHibernateSessionModule : IHttpModule
    {
        public void Init(HttpApplication context)
        {
            context.EndRequest += context_EndRequest;
        }
 
        void context_EndRequest(object sender, System.EventArgs e)
        {
            HybridSessionBuilder builder = new HybridSessionBuilder();
            ISession session = builder.GetExistingWebSession();
            if (session != null)
            {
                session.Dispose();
            }
        }
 
        public void Dispose()
        {
 
        }
    }
 
    public class UserRepository : IUserRepository
    {
        private ISessionBuilder sessionBuilder;
 
        public UserRepository()
            : this(new HybridSessionBuilder())// Ideally this would be injected, but as I don't think you are using an IoC container
        {
        }
 
        public UserRepository(ISessionBuilder sessionBuilder)
        {
            this.sessionBuilder = sessionBuilder;
        }
 
        public void SaveOrUpdate(User item)
        {
            WithTransaction(session => session.SaveOrUpdate(item));
        }
 
        public IEnumerable<User> GetAll()
        {
            ISession session = GetSession();
            return session.CreateCriteria<User>().Future<User>();
        }
 
        public User GetForId(Guid id)
        {
            ISession session = GetSession();
            return session.Get<User>(id);
        }
 
        public User GetForUserNameAndDomain(string userName, string domain)
        {
            ISession session = GetSession();
            return session.CreateCriteria<User>()
                .Add(Restrictions.Eq("UserName", userName))
                .Add(Restrictions.Eq("Domain", domain)).UniqueResult<User>();
        }
 
 
        private void WithTransaction(Action<ISession> action)
        {
            ISession session = GetSession();
            using (var tx = session.BeginTransaction())
            {
                action(session);
                tx.Commit();
            }
        }
 
        private ISession GetSession()
        {
            return sessionBuilder.GetSession();
        }
    }
 
}

FYI, Linq 2 NHibernate is still being worked on, but it shouldn't be too long

[Devart]

As for our company, we are not going to suppress our implementations of LINQ to SQL.
LINQ to Oracle, MySQL, PostgreSQL and SQLite are already available.

[NightStalker-DNS]

I use PLINQO. Which is a CodeSmith template that generates all the files for Linq 2 Sql, orcal or mySql depending on requirements.

[imaginekitty]

... EF would just not be feasible on a small project, where linq would be usefull. ...

Can you explain more about this? Why is EF not useable in a small project? Is it really that much more complex? How do you define "small project"?

I'm looking into LINQ to Entities now and am not seeing that much more complexity but I have not gotten very deep yet.