Explicit State Setting

May 10, 2014 at 10:17 AM
Edited May 10, 2014 at 10:39 AM
Is there a reason other than support for n-tier environments for the explicit entity state setting requirement of the framework? EF handles the state for you out of the box as long as the entities are attached to the context so the need for explicit state setting is somewhat redundant for applications where the context is accessible.

I think the project should be split between support for both models. Or make the option available for scenarios where the context is accessible. Adding support for this would not only drop having to explicitly set state, a couple added bonus' would include not having your entities derived from the Entity object which seems to pretty much only hold state and we can also remove the dependence of the framework from the Entities project and be able to reuse it with other ORM's easily.

I know it's a trade-off but I think you have made a huge assumption that the framework will be most likely be used in a n-tier environment. I would argue to the contrary.

I'd like your thoughts on this decision and if you have any plans to support the default EF state management which is supported out of the box.

For the time being, I have removed the IObjectState interface, the Entity class and any code that manages/syncs state for my use. Having to explicitly set state each time even though my entities are attached to the context is redundant and error prone IMO. I basically want the default state management of EF with your Repository framework minus IObjectState
May 12, 2014 at 5:13 AM
Edited May 12, 2014 at 5:16 AM
The framework is extensible and open source with the intent so you can do exactly as you have done which is to easily make framework level changes as you have done. For now we have to support the use case for updating object graph's between different DbContext's (and/or Bounded DbContexts) or simply when disconnected from the DBContext and this is the design pattern we are going with. Again, may not be the best for all scenarios (e.g. yours), so please make changes to the framework that best suites your architectural use cases.

This is also in place, for other Data Providers that we are planning to implement.

Out of the box, setting the ObjectState for your entities is a requirement. However, this can easily changed to use EF's state management as you have done.
Marked as answer by lelong37 on 5/11/2014 at 9:15 PM