OakLeaf Systems: Avoid the LINQ to SQL Data Objects vs. Business Objects Debate

Thursday, October 25, 2007

Avoid the LINQ to SQL Data Objects vs. Business Objects Debate

Dinesh Kulkarni's October 25, 2007 DTOs or Business Objects post explains the design philosophy behind LINQ to SQL without a direct answer to the question of "whether DLinq is for data objects or for business objects" or a definition that contrasts the two object types.

For starters, following are Wikipedia definitions:

In computer software, a Data Access Object (DAO) is an object that provides an abstract interface to some type of database or persistence mechanism, providing some specific operations without exposing details of the database. This isolation separates the concerns of what data accesses the application needs, in terms of domain-specific objects and data types (the public interface of the DAO), and how these needs can be satisfied with a specific DBMS, database schema, etc.
Business objects (BOs) are objects in an object-oriented computer program that abstract the entities in the domain that the program is written to represent. For example, an order entry program needs to work with concepts such as orders, line items, invoices and so on. Each of these may be represented by a business object.

Dinesh uses DTO (Data Transfer Object) in his title, so here's Martin Fowler's definition From Patterns of Enterprise Application Architecture:

An object that carries data between processes in order to reduce the number of method calls [across a connection].

The term DTO implies multiple tiers and crossing process boundaries. Dinesh has admitted that LINQ to SQL Has No "Out-of-the-Box Multi-Tier Story!", so the question resolves to DAOs or BOs.

Dinesh says "An entity maps to a single table or view and closely matches it in shape," which implies DAO but that statement doesn't take into account associated or subobjects (EntitySets and EntityRefs) that smack of BOs. Assuming a combination of a well-designed relational schema that corresponds to a BO with correctly named properties, the distinction between BO and DAO probably isn't significant. DAOs deliver BOs from tables of relational database management systems (RDBMSs). If you're into layers, LINQ to SQL in a class library provides a data access layer (DAL) with or without access to the DataContext object.

LINQ to SQL's essence is an object/relational mapping (O/RM) tool and persistence mechanism that offers the advantage of LINQ as a strongly-typed compiler-checked data query languate. Dinesh makes the point that, unlike some competing O/RMs, LINQ to SQL objects aren't "loaded with persistence-infrastructure like original state." Use of the graphic mapping tool's UI and code generation, as well as property value change notification, is optional. You can use plain-old CLR objects (POCOs) and gain whatever degree of persistence ignorance you think you need.

If you want to migrate low- to medium-complexity apps from table-oriented DataSets to modern object-oriented architecture and your back-end RDBMS (persistence store) is SQL Server 2000+ [Express], give LINQ to SQL a try. If you must use a different RDBMS, try a competing commercial or open-source O/RM or wait for Entity Framework and the appropriate data provider.

Update 10/26/2007: Jiri George Moudry's DB_LINQ (LINQ to MySQL, LINQ to PostgreSQL, and LINQ to Oracle) are in the alpha stage, and Kevin Kubasik has started a LINQ to SQLite project. See the "Prototype LINQ to SQL Clone DB_LINQ v0.11 Download" and "Work on LINQ to SQLite in Progress" topics of LINQ to SQL and Entity Framework Posts for 10/22/2007+ for more details and code download links.