Corrupting POCO Domain Model when creating LINQ Entity Classes?

Question

Say I've got a domain model created from C# classes like this:

public class MyClass
{
public string MyProperty { get; set; }
}

Along with the model, I have defined repository interfaces classes for IoC.

Now, I'm trying to turn this POCO domain model into a set of Entity classes using LINQ mapping. (This approch was recommended in a book I'm reading on MVC.) In the example above this was easy enough to do with a few attributes without impacting the 'plain oldness' of the classes:

[Table]
public class MyClass
{
[Column]
public string MyProperty { get; set; }
}

The problem comes when I start to map associations, change modifications and such. It seems that I'm quickly destroying the original concept of the domain model, and instead simply creating a set of LINQ-to-SQL classes. Am I missing something? Are these classes still the correct place for business logic? Will I still be able to and should I continue to load data into these classes from non-LINQ, non-DB sources?

Thanks

Answer 1

This post, also on SO, answers my question: (Thanks Google)

Entity classes decoupled from LINQ to SQL provider for implementing the Repository pattern. How?

EDIT:

Well maybe not, is this a common complaint about entity classes?

ANOTHER EDIT:

Ok, so basically this cannot be done at the moment, but with .NET 4.0 it is supposed to be possible.

Answer 2

There have been several other question like this.
I played with EF4 this week end, you can follow Julie Lerman blog post serie to implement a Repository pattern with EF4. It works well, although it's no yet completely straight forward...
As far as I know there is no way to do this with EF3.5. Good luck.