Should Business Logic objects have knowledge of their LINQ-to-SQL data objects?

Question

I've looked at several similar questions but I didn't see any that directly applied to me, so forgive me if this is a duplicate.

For separation of concerns I'm trying to somehow map my business objects with logic to the LINQ to SQL data objects in the .dbml file (fairly new to this btw). What its looking like though is that my business objects are going to need to know about the corresponding LINQ2SQL objects. I read this article about trying to use POCOs with by using an xml mapping file, and it seems like that's similar to what I want, except that I don't have a one-to-one mapping from tables to classes because of a many-to-many relationship that I needed to create an extra table for.

I can encapsulate the data access in my business logic pretty well such that code that uses my business objects don't need to know anything about the database which is good, but it the business layer is still tightly coupled with the data access layer such that I couldn't swap out the DAL without either changing my business layer objects or creating new ones (that implement the same interfaces) for different data providers.

How can I decouple these layers?

Answer 1

Not sure if you are tied to LINQ to SQL somehow, but what you are trying to accomplish is pretty much the default in NHibernate. I recommend taking a look at NHibernate to see if it would be easier to switch than to fight LINQ to SQL.

I've found that fighting a tool is almost always a bad idea.