Corrompendo POCO modelo de domínio ao criar LINQ Classes de entidade?

Question

dizer que tenho um modelo de domínio criado a partir de classes C # como este:

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

Junto com o modelo, eu tenho definido classes de interfaces de repositório para IoC.

Agora, eu estou tentando transformar este modelo de domínio POCO em um conjunto de classes de entidade usando mapeamento LINQ. (Este approch foi recomendado em um livro que estou lendo no MVC.) No exemplo acima, isso foi fácil o suficiente para fazer com alguns atributos sem afetar a 'velhice plain' das classes:

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

O problema vem quando eu começar a mapear associações, modificações de mudança e tal. Parece que eu estou destruindo rapidamente o conceito original do modelo de domínio, e em vez de simplesmente criar um conjunto de classes LINQ to SQL. Estou esquecendo de algo? São essas classes ainda o lugar correto para a lógica de negócio? Ainda serei capaz de e devo continuar a carregar dados para essas classes de não-LINQ, fontes não-DB?

Graças

Answer 1

Este post, também no SO, responde a minha pergunta: (Graças Google)

As classes de entidade dissociada da LINQ para provedor de SQL para implementar o padrão Repository. Como?

EDIT:

Bem, talvez não, esta é uma queixa comum sobre classes de entidade?

OUTRO EDIT:

Ok, então basicamente isso não pode ser feito no momento, mas com .NET 4.0 é suposto ser possível.

Answer 2

Houve vários outros pergunta como esta.
Eu joguei com EF4 este fim de semana, você pode seguir Julie Lerman post no blog serie para implementar um padrão de repositório com EF4. Ele funciona bem, embora ele não é ainda completamente em linha reta para a frente ...
Tanto quanto eu sei não há nenhuma maneira de fazer isso com EF3.5. Boa sorte.