My company has thousands of classes and methods that use the DataAccessAdapter generated from LLBLGen Pro. We are looking for a seamless way to take advantage of Linq. The new Linq templates seem to work great, better than the Microsoft VS generated code. Because we don't have the ability to switch every class/method over to Linq all at once, we need both to exist at the same time for a year or so. This would allow us to slowly migrate code to use Linq as things get updated.

I've written a simple test to see if I could get both to coexist. It worked great. What I would like to know is if you see any potential problems with doing this. Without access to the DataAccessAdapterBase code, we really don't know what housekeeping it is doing under the hood that might conflict with this solution.

Here's the code I used for my test. First is a "LinqExtensions.cs" file that is included with our DataAccessAdapter to expose a couple things we need access to. The second part is the actual test.

Thanks for your help,

Kent

namespace Cology.DAL.DatabaseSpecific
{
    public partial class DataAccessAdapter : DataAccessAdapterBase
    {
        /// <summary>
        /// Returns the active connection object, if none exists, one is created.
        /// </summary>
        public IDbConnection ActiveConnection
        {
            get
            {
                return this.GetActiveConnection();
            }
        }

        /// <summary>
        /// Returns the active transaction, if none exists, it returns null.
        /// </summary>
        public DbTransaction ActiveTransaction
        {
            get
            {
                if (this.PhysicalTransaction != null)
                    return (DbTransaction)this.PhysicalTransaction;
                return null;
            }
        }
    }
}

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            bool transact = true; //Switch to test w/ transaction or w/out

            //Create the LLBLGen Data Access Adapter
            DataAccessAdapter adapter = new DataAccessAdapter();

            //Let's start a transaction
            //This should actually call IDbTransaction.StartTransaction
            //That means it's transaction on the connection, not the adapter/context
            //We need to flag the active transaction on BOTH the Data Adapter & Data Context
            if (transact)
                adapter.StartTransaction(IsolationLevel.ReadCommitted, "TestTransaction");

            try
            {
                //Do Something with the Data Access Adapter
                UserAppEntity uae = new UserAppEntity("kwilliams", "TUITIONU");
                adapter.FetchEntity(uae);
                uae.DataAccessLevel = "SUPER";

                //Save the data access adapter
                adapter.SaveEntity(uae);

                //Do something with Linq code
                DoSomethingLinq(adapter);

                if (transact)
                    adapter.Commit();
            }
            catch
            {
                if (transact)
                    adapter.Rollback();
            }
            finally
            {
                adapter.Dispose();
            }
        }
        public static void DoSomethingLinq(DataAccessAdapter adapter)
        {
            //Reuse the same connection
            CologyDataContext db = new CologyDataContext(adapter.ActiveConnection);
            //Make sure the transaction is set
            db.Transaction = adapter.ActiveTransaction;

            //Do Something with the Data Context
            UserApp me = db.UserApps.Single(u => u.UserName == "kwilliams" && u.AppName == "SCHOOLACCESS");
            me.DataAccessLevel = null;

            //Save the data context
            db.SubmitChanges();
        }
    }
}

If you want to use our linq support, why do you need DataContext? DataContext is linq to sql.

LLBLGen Pro v2.6 has its own support for linq build in, so you can keep using llblgen pro, the dataaccessadapter code, and use linq queries when you want/need. So for the requirement to use linq as the query api, you don't need linq to sql, you can use our linq provider (v2.6)

E.g. your linq to sql query would be: LinqMetaData metaData = new LinqMetaData(adapter); var q = metaData.UserApps.Single(u => u.UserName == "kwilliams" && u.AppName == "SCHOOLACCESS");

As you see, same query, but it uses llblgen pro and not linq to sql.

MIxing o/r mappers is not really 'mixing': you're simply using two different pipelines with different objects etc. I wouldn't go there as it would make the application very hard to maintain.

Ahh. We're using LLBLGen Pro 2.0 here. Is their a free upgrade to version 2.6?

From the pricing page...

There are no additional or hidden costs. Updates and upgrades within a version are free, as is our very fast support.

If you log into the customer area you should be able to download 2.6.

Matt