2009-07-09 13 views
5

Decir que tengo un modelo de dominio creado a partir de clases de C# como esto:Modelo de dominio corrupto de POCO al crear clases de entidad LINQ?

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

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

Ahora, estoy tratando de convertir este modelo de dominio POCO en un conjunto de clases de Entidad utilizando el mapeo LINQ. (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 comienzo a mapear asociaciones, cambiar modificaciones y demás. Parece que estoy destruyendo rápidamente el concepto original del modelo de dominio, y en su lugar simplemente creando un conjunto de clases LINQ-to-SQL. ¿Me estoy perdiendo de algo? ¿Siguen siendo estas clases el lugar correcto para la lógica de negocios? ¿Seguiré siendo capaz y debo continuar cargando datos en estas clases de fuentes que no son de DB y de LINQ?

Gracias

+0

Además, ¿podría ser una buena razón para usar archivos de mapeo externos? ¿Algún pros/contra para este enfoque en este contexto? – Paul

Respuesta

0

Ha habido varias otras preguntas como esta.
Jugué con EF4 este fin de semana, puede seguir Julie Lerman blog post serie para implementar un patrón de repositorio con EF4. Funciona bien, aunque todavía no es completamente sencillo ...
Por lo que sé, no hay forma de hacerlo con EF3.5. Buena suerte.

Cuestiones relacionadas