Corrompiendo Modelo POCO dominio al crear clases de LINQ entidad?

Question

Digamos que tengo un modelo de dominio creado a partir de clases de C # como esto:

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

Junto con el modelo, he definido clases de interfaces de repositorio para COI.

Ahora, estoy tratando de convertir este modelo de dominio POCO en un conjunto de clases de entidad utilizando LINQ mapeo. (Este approch fue recomendado en un libro que estoy leyendo en MVC). En el ejemplo anterior esto era bastante fácil de hacer con unos pocos atributos sin afectar la 'vejez normal' de las clases:

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

El problema viene cuando empiece a trazar asociaciones, cambiar modificaciones y tal. Parece que estoy destruyendo rápidamente el concepto original del modelo de dominio, y en lugar de la simple creación de un conjunto de clases LINQ a SQL. ¿Me estoy perdiendo de algo? Son estas clases sigue siendo el lugar correcto para la lógica de negocio? ¿Seguiré siendo capaz de y debería continuar para cargar datos en estas clases de no-LINQ, fuentes no DB?

Gracias

Answer 1

Este post, también en SO, responde a mi pregunta: (Gracias Google)

clases de entidad disociada de LINQ al proveedor de SQL para implementar el patrón Repositorio. ¿Cómo?

EDIT:

Bueno, tal vez no, esta es una queja común acerca de las clases de entidad?

otra edición:

Ok, así que básicamente esto no se puede hacer en este momento, pero con .NET 4.0 se supone que es posible.

Answer 2

Ha habido varios otros pregunta como esta.
Jugué con EF4 este fin de semana, puede seguir Julie Lerman entrada de blog serie para implementar un patrón de repositorio con EF4. Funciona bien, aunque no es todavía completamente recta hacia adelante ...
Por lo que yo sé no hay manera de hacer esto con EF3.5. Buena suerte.