Thoroughly by Contract?

Aug 9, 2014 at 9:02 PM
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
Aug 9, 2014 at 10:41 PM
Edited Aug 9, 2014 at 10:48 PM
As a further consideration, I messed around with the arrangement of the Entity abstract base class for the models.

I found that I was able to use an Interface of a model as a generic parameter to the Repository generic class. I had to have the model derive from the Entity base class in repository.ef6. After that I as able to refactor an interface from the model that included a new not mapped ObjectState property. Then, on the model Interface I had created, I made it derive from the IObjectState interface in the repository (not ef6).

At that point, I could use the Interface for the model in the generic Repository<TEntity> class in repository.ef6. (new Repository<ICustomer>()) without getting the error indicating the Interface of Customer does not implement the IObjectState interface.

That means that neither the IObjectState interface on the Entity object, nor the Entity base class itself is sufficient to identify an Interface based on the inheritance combination of the Model and Entity base as an acceptable contract of the Model derived from Entity . The interface of the model requires its own inheritance from IObjectState to satisfy that requirement.

This modification is sufficient to separate the EF implementation artifacts out of the contracts that reference the models, and it seems to work on the implementation side since the concrete models actually do implement the Entity base class as well.

Now, despite finding a way to make it work (to an extent I would have to call 'so far') I am still interested to know... was it convenience or strategy that drove your decision to use references to concrete models in your contracts?

Again, my goal is to determine whether its possible to completely abstract the implementation details of the underlying framework out of a 'contract framework' such as the one you are so kindly providing. Or are there still gotcha's that require that the contracts sometimes make use of references to concrete objects with their embedded artifacts from the lower-level frameworks?

Thanks again,

Kimball
Developer
Aug 11, 2014 at 11:49 AM
@kimballjohnson. It's hard to understand what you are doing here, could you please fork the framework and commit your changes to the fork so I can take a look at them? I have a lot of responses to your initial post, but it would help a lot to have a look at the changes you describe before answering.
Marked as answer by lelong37 on 8/11/2014 at 2:27 PM
Coordinator
Aug 11, 2014 at 10:23 PM
I have to agree with AGBrown, it's a bit difficult to understand and/or visualize what you are trying to do and the concern you are addressing. A pull request or fork depicting this would be nice of even a simple diagram that you can post here would be helpful.
Aug 14, 2014 at 10:24 AM
I appreciate your responses. I will be happy to provide you a modified version of your sample project with the changes I described.

However, I may be a day late due to some project issues.

Nonetheless I will be able to merge these changes back in and submit proably by Friday, certainly by Saturday.

Kimball