Linq Data Services and the Business Logic Layer

Linq is great.  However, about the 2nd or 3rd question after using it is "how to I do a 3-tier or layered model with LINQ?..."  Unfortunately, there appears to be no easy answer to this.  It appears Linq was designed primarily as a client side library for a 2-tier system - and it works great for this.  Moving to a layered 3-tier model can still be done, but is not straight forward and still requires a lot of manual work with containment and/or data transfer objects. Microsoft seems to be staying mute on the issue for now until they get some good patterns documented. Myself, I am looking forward to a post promised by Scott Guthery on the issue.  There are a few blog posts on different approaches (see Links below).

I was hoping Linq to Entities would solve this problem by allowing some form of remote business logic layer (BLL) that would run on the server and could be accessed via Linq to Objects on the client side.  It appears that is not the case.  IMO, this model is exactly what is needed. Microsoft's Astoria sort of hints at this type of thing but nothing I have seen so far seems to nail the issue head on as I would like to see as a developer.

Desired Feature List

• A WCF service model that hosts our BLL. I will call this the LinqDataServiceBLL. As a WCF service the BLL layer can be hosted remotely or in-process.
• The BLL service (if run on same server as SQL) will have a Direct Pipe into SQL for direct access to the engine. This means we don't need the added overhead of a linq to TSQL conversion or the ADO layer - it would be direct.
• The BLL service will talk to the DB via LinqToEntities vNext.  The public API would be same as today (with any upgrades), but the bottom would be able to talk directly to sql via some kind of direct pipeline.
• A LinqToDataServices on the client that will talk to the LinqDataServiceBLL locally or remotely.  This would look and feel like LinqToSql on the surface, but talk to LinqDataService on the back-end instead of using ADO and converting a nice query expression back into a SQL string so it can then turn around to be parsed by the server and run (as what happens today).
• Remove the need for for last domain specific language I need - TSQL.  I now that sounds like crazy talk, but isn't this exactly why Linq was created in the first place?  Even with Linq today, you really can't stay out of TSQL.  If we need update logic, this typically still requires a well written storage procedure written in TSQL. TMK, things like Atomic test and set operations can not be done on the client side using Linq. For example, lets say you want to update a TimeOut datetime column if it exists, or add a new record if it does not *and do this in an Atomic operation that is not effected by other users also doing updates. This is actually a common need that should be simple.  Even using TSQL, this kind of operation is tricky and requires deep knowledge of TSQL and db locking behavior (as shown by this NG Thread). IMO, this is not the world I want to live in.  I want to stay in c# and linq and not have to transition into TSQL or sprocs - Ever again.  Having proper support in the LinqToEntities layer means I would never have to write another sproc or touch TSQL.  And why should I - it can be abstracted away.
• Methods instead of SPROCs. The public methods in the LinqDataServiceBLL and the LinqToEntities really become your sprocs.  They talk directly to the db engine so you don't need sprocs.  Maybe they act as delegates or lambas that are executed directly by the DB engine.  It will just be abstracted so the implementation details are not important (but interesting). DB locking syntax would need to be added to Linq.

A High level example

The picture below tries to show how this may work.

1. The client side uses LinqToDataServices.  This will feel like LinqToSql, but talk to the DataService instead of ADO to the DB.
2. The LinqDataService will be a WCF service.  This will contain *all your business logic for CRUD operations.  In a sense, all your c# (or vb) methods become sprocs without being sprocs.  They may be out-of-process or in-process to the DB engine or a combination of both. The key is, they will have direct access to the DB engine via the LinqToEntities layer that will have a hot memory pipe to the DB.  The method below will hopefully demonstrate the idea:

   [OperationContract]
   public void PunchOut(int empID)
   {
       DbContext db = DbContext;

       if (!db.User.MemberOf("GoodUser")) throw new SecurityException("Not allowed");
       Employee emp = db.Employees.FirstOrDefault(e=>e.EmpID==empID);
       if (emp==null) throw new InvalidOperationException("Employee not found");
       
       // atomic test and set example. May need some work.
       dbLock(db.TimeEntries.Update) // Grab update lock on table.
       {
            TimeEntry te = emp.TimeEntry.LastOrDefault();
            if (te == null || te.OutTime != null)
               throw new InvalidOperationException("Must punch in first.")
            te.OutTime = DateTime.Now;
            db.SubmitChanges();
       }
   }
   
   
   

   Note the method looks like a normal method. However, it uses the LinqToEnties context to get access to the DB. It also has access to db locks from c# code. Not sure how this may actually be
   implemented. Maybe the whole method is converted to a lambda delegate that is run in-proc by the DB. Maybe it is converted at compile-time to a CLR sproc, or maybe something else. However,
   
   the developer does not need to know the details, it just feels looks and feels like a method. Tons easier and faster then having to stop and write a TSQL sproc. Also debugging is more natural, etc.

   Now that is a framework I would really love to see. Hope that makes some sense.

   -- William Stacey [C# MVP]