How should I handle Entity / Domain objects using IoC / Dependency Injection?
I am currently using PLINQO to generate all my entities from the database.
Lately I've started using Dependency Injection using StructureMap as well as part of the learning process to "separate my concerns". I noticed that all the Entity classes generated contain highly connected properties using the EntitySet, part of LINQ, that make my objects depend on using System.Data.Linq.
I would like to keep using my PLINQO created entities, but at the same time it seems to me that I should probably generate some kind of base class / data only objects and maybe even move them to another assembly, then use some kind of then an auto-translator to convert between them if needed. At best (or worst of all, depending on how you look at it), I would like some interfaces to represent them so that later I can add them to other concrete types.
Is this excess? At the end of the day, I'll be moving away from using SQL Server directly to using web services, and I doubt EntitySets will easily go over the wire.
Does anyone have any good examples of working with a script like this?
TIA
source to share
I think you are on the right track - don't let the name of the generated L2S classes fool you. These are not entities in DDD terminology, but simply strongly typed views of the database. If you ask me, this is an implementation detail that should not allow intrusion into the domain level.
With currect.NET framework, and if you stay exclusively with BCL and don't use additional libraries, your only option is to define consistent entities in your domain model and then map them to the L2S classes in the data access layer. It's a pain, but AutoMapper can be helpful in this regard.
If you want to stray a little from pure BCL, there are open source libraries that offer ignorance of ignorance, like NHibernate - I have no personal experience with NHibernate, but many smart people value it highly.
In .NET 4.0, Entity Framework and therefore LINQ to Entities will also offer ignorance of ignorance .
Jeremy Miller has a MSDN article that touches on the topic somewhat .
source to share