5

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

Paul
  • 6,188
  • 1
  • 41
  • 63
  • Also, might this be a good reason to use external mapping files? Any pros/cons to this approch in this context? – Paul Jul 09 '09 at 18:48

2 Answers2

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.

Community
  • 1
  • 1
Paul
  • 6,188
  • 1
  • 41
  • 63
0

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.

Stéphane
  • 11,755
  • 7
  • 49
  • 63