How should I handle my Entity/Domain Objects using IoC/Dependency Injection?

Question

I'm currently using PLINQO to generate all my Entities from the database.

Recently, I've started to use dependency injection using StructureMap, and as part of the learning process of "separating my concerns". I've noticed that all the generated Entity classes contain highly-coupled properties using EntitySet, part of LINQ, which make my entities dependent on using System.Data.Linq.

I would like to continue to use my PLINQO generated entities, but at the same time, I feel like I should probably generate some sort of base-classes/data-only objects, and perhaps even move them in to a different assembly, then use some sort of auto mapper to convert between the two, as needed. At best (or worst, depending how you look at it), I'd like some interfaces to represent these, so that I can inject them with different concrete types later.

Is this overkill? Eventually, I'll be moving away from using SQL Server directly to using Web Services, and I doubt those EntitySets will go over the wire that easily.

Does anyone have some good examples of working with a scenario like this?

TIA

Answer 1

I think you are on the right track - don't let the name of the generated L2S classes fool you. They are not Entities in the DDD terminology, but simply strongly typed representations of the database. If you ask me, that is an implementation detail that should not be allowed to invade the Domain Layer.

With the currect .NET framework, and if you stay purely with the BCL and use no extra libraries, your only option is to define persistent-ignorant Entities in your Domain Model and then map those to the L2S classes in the data access layer. It's a pain, but AutoMapper can be helpful in that regard.

If you are willing to deviate a bit from the pure BCL there are open-source libraries that offer persistence ignorance, such as NHibernate - I don't have any personal experience with NHibernate, but lots of smart people think highly of it.

In .NET 4.0, the Entity Framework, and thereby LINQ to Entities will also offer persistence ignorance.

Jeremy Miller has an article in MSDN Magazine that somewhat touches upon the subject.