New Post: Thoroughly by Contract?

I am enjoying working with your framework. It's a pleasure to work with a mechanism that thoroughly abstracts away the EF artifacts.

But I'm a little surprised by the lack of interfaces for your models. I've been used to representing all objects in the data chain using interfaces, including models.

I've sorted out the issues and come to the conclusion that your use of a concrete Entity as the base class for all models is the point where the EF artifacts still remain attached to the contract. Its the objectstate artifact that allows EF to show its influence.

To me, separation of concerns is implemented by contract, which implies a repository with a generic typed with the interface of a model, not with a concrete type of a model.

This makes me expect that you would implement an IEntity interface for the IModel and have the ObjectState represented in the IEntity as IObjectState. I believe EF already has an IOBjectState interface, but at least everything would be abstract.

Today we use IOC rather than factories to deliver concrete implementations that include and incorporate all the ugly facts about the frameworks we base our code on. That technique is better than having hundreds of factories to produce factories of factories.

But have you made the choice to have your contracts refer to concrete objects to shortcut some things? Or are there true impossibilities in abstracting EF that require this type of compromise?

Thanks,

Kimball