Discussion about API changes necessary for POCO:

a-foton » Discussion about API changes necessary for POCO:

a-foton » Discussion about API changes necessary for POCO: — Fri, 01 Aug 2008 19:51:30 GMT

PingBack from http://blog.a-foton.ru/2008/08/discussion-about-api-changes-necessary-for-poco/

re: Discussion about API changes necessary for POCO:

Kosher — Sat, 02 Aug 2008 12:01:42 GMT

I certainly hope this isn't replacing ADO.NET. I do appreciate the rewrite and there are some drawbacks to the existing ADO.NET paradigm but I think it has evolved quite nicely with the introduction of LINQ to DATASET.

I hope you realize this is duplicating many of the ideas and features that already exist in DataSets.

re: Discussion about API changes necessary for POCO:

dsimmons@microsoft.com — Sat, 02 Aug 2008 20:39:06 GMT

The Entity Framework will not replace ADO.NET--it builds upon ADO.NET, and we will support both. There will continue to be reasons for using ADO.NET. It might be that this is just the style of coding you prefer or it might be that you want to use the EF but occassionally need to go around the EF and talk more directly to the DB or whatever.

The EF has its place and so does ADO.NET (including DataSets).

- Danny

re: Discussion about API changes necessary for POCO:

jstangroome — Tue, 05 Aug 2008 13:37:26 GMT

Regarding Q3, a big pain with DataSets is that invalid data cannot be entered. Sure, invalid data should not be able to be committed to the database but the in-memory object should be able to be in an inconsistent state until the app/user corrects it.

Therefore EF POCOs should allow invalid state without throwing exceptions.

Regards,

Jason

Entity Classes & Architecture Patterns

system.data.objects dev guy — Sun, 10 Aug 2008 11:09:27 GMT

Entity Classes & Architecture Patterns Part of the Entity Framework FAQ . 2. Architecture and Patterns

Entity Classes & Architecture Patterns

system.data.objects dev guy — Sun, 10 Aug 2008 11:12:33 GMT

Entity Classes & Architecture Patterns Part of the Entity Framework FAQ . 2. Architecture and Patterns

re: Discussion about API changes necessary for POCO:

Colin Jack — Mon, 11 Aug 2008 18:19:58 GMT

Q1 - UOW and validation, whilst UOW is great it would be good if we could perform validation before you commit to ensure that totally invalid information is not persisted. This should be done in a nice clean way and should allow us to do the validation any way we choose.

Q2 - Make it implicit so alternative 2. People are used to the UOW pattern so I think this approach is fine.

Q3 - Just throw the exception at the last minute, this isn't a major issue so in my view so don't worry about it. Reassigning the ID of a mapped class is a coding error and if we don't catch it in tests an exception at run-time is totally fine. EntityState is not an attractive option at all.

re: Discussion about API changes necessary for POCO:

Jarod Ferguson — Tue, 12 Aug 2008 08:58:25 GMT

I’ve had some issues with my comments not posting when logged in. Finally got a chance to type this again...

-----

Tracking state to POCO entities/graphs while detached from the context

-Scenarios: WCF/Web Services, SilverLight, ASP.NET presentation tier (non EDS)

-----

Though DetectChanges is not ‘that’ intrusive (dev should be aware) it seems the default behavior should be ‘built-in’ as in alternative 2. I guess it would all come down to perf. Though a con of alternative 1 is potentially iterating through a large number of items in the state manager dictionaries, it seems as though the same issue might exist for alternative 2 ( as in saving changes). – Could it be possible to support both at some point by configuration?

-----

#3 –

Invalid state seems as though it could have advantages being combined with other states. Again, it would be cool at some point to support both, defaulting to throwing exceptions by default with the ability to enable Invalid States.

-----

I think the best scenario is the Dynamic Proxy with notification based tracking. Would code enhancement (IL modification/injection) be an option vs. dynamic proxy to alleviate the need for virtual properties?

If mixed mode was used I would prefer to call DetectChanges. It seems like it might be advantageous to have some properties state explicitly controlled, while others are tracking automatically with notification based. This would allow a dev to update parts of an entity. (Cant think of any good reason for this yet, but I’m sure I could find something)

re: Discussion about API changes necessary for POCO:

Colin Jack — Tue, 12 Aug 2008 10:19:23 GMT

"I’ve had some issues with my comments not posting when logged in. Finally got a chance to type this again..."

Yeah I've had this every time I try to post on the EF blog, tried 4 times on one post and nothing appeared. Very frustrating.

re: Discussion about API changes necessary for POCO:

macsgold — Thu, 14 Aug 2008 08:38:05 GMT

Add the ability to require a POCO entity to be explicitly 'registered' for snapshot tracking (including its relationships?). E.g. POCOs may not all come from the context anyway. This obviates the performance problem of DetectChanges having to iterate through too much, because you only have to iterate through what is registered (only a subset of entities may need to be modified).

Snapshot (or notification) state management must support true 'savepoints' to model nested units of work (e.g. popup cancelable modal edit dialogs in a UI, or any type of undo to a pre-specified savepoint).

Following on from the above, state managements need to support TransactionScope - i.e. implicit savepoints and rollbacks to them on a TransactionScope rollback. Ideally to be able to participate in distributed transations.

State managements need to be extensible (interface based), with events to hook or methods to override, and also be fully replaceable.

DetachChanges() should be public and not throw exceptions for validation changes (separate structure or method for querying that). EDM constraints are only a subset of an overall validation model so don't have exceptions dictate an implementation approach (i.e. the output of DetectChanges() is valuable with or without EDM validation errors). (Jason says this earlier.)

Making and restoring (overwriting an entity) of snapshots of entities should be able to use a custom 'serialization' mechanism if desired, e.g. to support customization of the 'restore' process (talking about an undo or 'rollback' here) for any custom code that needs to be run (e.g. (re)setting any transient properties).

POCO scenario: 'context-free', save-pointable, TransactionScope-aware, efficient querying of what is modified.

Cheers,

-Mat Hobbs

re: Discussion about API changes necessary for POCO:

Eugene Burd — Fri, 15 Aug 2008 18:43:40 GMT

1. I have had times where it was not enough to know that an object was changed, but I actually needed to know what changed. The fact that the object changed, means that it needs to be persisted; however, if I have another system that only cares about certain changes, i wouldn't want to notify it of these changes unless it was necessary.

2. Interesting dilemma. From a pure academic point of view, I would say that since ObjectStateEntry.State is a property, best design practices would say it shouldn't do any heavy lifting (should be deterministic). However, in this case, I think the best decision is to break this rule. I just think its dangerous to return wrong values to a developer who is ill aware of the new changes to the API. This is almost worse than breaking the interface, it preserves it, but alters the functionality. So alternative #2 seems better to me. One potential way to speed things up is to take a checksum of the scalar fields of an entity and store it along with the state. That way when subsequent calls are made to properties / methods that require the recomputation of state, it could be done faster, since if the checksum was the same, you would know that there were no changes from the previous computation. Just an idea.

#3 - I don't have strong feelings on this one either way you go. Since its too late to correct anything, it seems like throwing an error would be a good thing.

re: Discussion about API changes necessary for POCO:

Alexnaldo Santos — Thu, 21 Aug 2008 20:41:12 GMT

Q1, Q2 and Q3

To manager business I need sinals to make decisions at any time, no matter scenarios.

If I'm working with business objects (tables) and it have components (columns)

I need to know the states of both at same time and together, no matter the Tier(WCF,ASP,WinForm, etc.).

IMHO, IPOCO is the best option but without to implement many

interfaces. I don't like the idea that another object(ObjectStateManager)

control the states of objects.No problem to "identity management" but wrong for "State management".

If I'm bad I say to my doctor "I'm bad.."

and not my doctor say to me "you are bad". The state of me and any part of my

body can't live out me. I think like it to object too.

So, I would like to see in my objects :

myObject.State ( readonly, already exists )

myObject.Undo() ( undo the changes )

myObject.Columns["MyColumn1"].State ( readonly, the state on my column )

myObject.Columns["MyColumn1"].OldValue ( readonly, the old value of my column )

myObject.Columns["MyColumn1"].Value ( readwrite, the current value )

myObject.Columns["MyColumn1"].Undo() ( undo the changes )

myObject.MyColumn1 ( readwrite, the current value )

I'm using this approach with "Linq to Sql" and work very well.

Now, I would like to "migrate" my objects to EF.

My table will be like it :

[Serializable]

[DataContract]

public class MyIPocoClass : IEntity

{

public MyIPocoClass()

{

}

private EntityState _state;

[DataMember]

public EntityState State

{

get { return _state; }

}

[NonSerialized]

private EntityColumns _columns;

[XmlIgnore]

public EntityColumns Columns

{

get

{

if (_columns == null)

{

_columns = new EntityColumns();

_columns.PropertyChanging += new PropertyChangingEventHandler(OnPropertyChanging);

_columns.PropertyChanged += new PropertyChangedEventHandler(OnPropertyChanged);

}

return _columns;

}

public event PropertyChangingEventHandler PropertyChanging;

public event PropertyChangedEventHandler PropertyChanged;

protected virtual void OnPropertyChanging(object sender, PropertyChangingEventArgs e)

{

if (PropertyChanging != null)

{

PropertyChanging(sender, e);

}

protected virtual void OnPropertyChanged(object sender, PropertyChangedEventArgs e)

{

if (PropertyChanged != null)

{

PropertyChanged(sender, e);

}

[DataMember]

public string MyColumn1

{

get { return Columns.GetValue("MyColumn1") as string; }

set { Columns.SetValue("MyColumn1", value); }

}

re: Discussion about API changes necessary for POCO:

jrista — Sat, 23 Aug 2008 02:44:25 GMT

Q1: WCF & Disconnected Entities.

In v1 of EF, its a bit difficult to effectively use entities on the client in an SOA environment. Part of this is due to how the available tools generate WCF proxies...either it generates all types for you, or you can share the exact same types in the exact same assembly as the service. The problem with EF entities is they come with an ugly parent class chain from the System.Data.Entity assembly, and all that stuff ends up cluttering your Presentation Layer. POCO can solve this problem, since they are just plain old classes, but you have the problem of serializing a modified POCO graph back from the client to the service and persisting those modifications to your data store.

There are some options here, like keeping the ObjectContext around until the UOW is complete...but that means keeping it around accross multiple calls to the service, which means plumbing code. You could wrap up all object graphs in a utility class that tracks changes for you on the client, but then your binding both your service and your clients to a utility class that gets in the way of clean, simple use of your entities. Some kind of mechanism is needed to keep track of state accross object context instantiations, and it should be transparent so that POCO entities in an SOA environment can be used as simply as possible without requiring loads of plumbing and support code to keep track of changes and apply those changes to the ObjectStateManager.

Q2: Neither is better, both are neccesary.

Your developing a base platform upon which thousands and eventually millions of applications will be built on top of. In my experience over the last 6-8 months, the greatest problem in EF is its seemingly endless LIMITATIONS. In its current form, EF has such a nitch place because it limits and restricts to the nth degree. For EF to become truely viable as an O/R Mapping platform that can provide true value to the very wide variety of applications written on and for the windows platform, you need to eliminate limitations and restrictions on what is possible.

So, in regards to question 2...don't pick one...use both. Keep the framework as flexible as possible and support as many scenarios as possible. There is no one single way to write a program, and while there are few proper ways and many improper ways to implement a design, there are still a few proper ways. Support both state management methodologies, and you'll keep more people happy and make EF viable for the broadest range of applications.

Q3: Don't Restrict and Limit.

Just as in Q2, your building a base framework upon which applications will be built. Don't impose MORE limitations on the consumers of your framework...eliminate them. There are going to be times when temporarily having Invalid State for a property is going to be neccesary to support what a developer needs. By immediately throwing an exception, you completely eliminate that option, and force a developer to invest more time finding a way around your imposed limitation.

Allow invalid state...only throw an exception when its absolutely neccesary (i.e. persisting state to the data store.)

I think EF has immense potential, but my overall experience, and particularly my experience since the release of v1, has been dismal. I have effectively given up on implementing EF in the near future, possibly for the forseeable future, because of the boundless limitations that I am continually running into. Most of the practical, proven, and effective methodologies for software development, such as DDD (Domain Driven Design), offer wonderful guidelines to developing stable, maintainable, and extensible software...yet EF does not support these common architectures and scenarios except in very limited capacity. (i.e. EF is still highly data-driven and limited in its O/R Mapping capabilities, and does not allow the DOMAIN to drive design decisions...it enforces schema-bound restrictions). That should change with EF v2.

re: Discussion about API changes necessary for POCO:

Shlomi — Wed, 27 Aug 2008 19:08:33 GMT

Talking about snapshots - my wish for your next release is to see a rollback mechanism which supports TrasactionScope. if the scope fails - the context returns to what it was before the transaction.

re: Discussion about API changes necessary for POCO:

Gatecrasher — Wed, 27 Aug 2008 19:22:02 GMT

I created, like many others, entity classes derived from the database tables/Sp's. I also implemented the "State" field (modified, deleted etc) and latched that to events used to implememt the databinding interfaces.

Like someone else has said knowing it's changed is sometimes not enough, you need to know what has changed. You could argue that if that is the case use a DataSet which implements the "before/after" model. This of course has the drawback in that it doubles that amount of data being passed around.

The other area that needs consideration is DataBinding at the client. Various interfaces allow data binding to "undo" changes (start/endedit) and synchronise code/screen updates through their respective managers. Databinding works very well with datasets but not so well with Linq to SQL (I understand) so maybe some lessons there.

My problem was with databinding and serialization. To support Databinding I implemented the required interface and the notification events. Tied into those properties I modifed the "state" at the same time.

Of course the properties that raised these events are called by the serializer. So during a web service call "everything" becomes "modified".

Being able to pass "work in progress" across serialization boundaries and have the state maintained is vital.

Ideally the properties need to know when they are being called by the serializer and in .NET2 the XML serializer is not very helpful, there are no "before" and "after" events to latch onto. The Binary serializer and WCF both implement these now I think.

My "cludge" was to event a "first" and "last" property to set and clear a flag and fix the "field order"!! These properties would only ever get called when serializing (I hope) so could enable and disable the change events. With WCF is can de-gludge my code I think.

One thing I considered was using a Property/Hashtable type structure rather than the usual Property/Private field. Optionally using 2 hashtables to store before and after. The 2nd hashtable storing only fields that have changed and storing the original value. Of course you need a serializable Dictionary<> object which I wrote too.

I like the hastable approach, you only store twice at the field level when the field changes. Any records in the 2nd table means "modified". No changes means no XML when serialized unlike a DataSet which always stores everything twice so doubles the XML created.

Where I work data load across the network is a "big thing", hence our interest in WCF and Binary serialization!!

Breaking "hassle free" databinding is a reason we haven't touched Linq for SQL.

My story is simply pointing out that serialization, data load size, network performance and support for client Data Binding must all be factored into any decision.

re: Discussion about API changes necessary for POCO:

Gatecrasher — Wed, 27 Aug 2008 19:28:43 GMT

I forgot to say that Dictionary<> objects do serialize the "key" which creates big XML too. One reason I looked at it and then didn't bother!

re: Discussion about API changes necessary for POCO:

Greg Young — Tue, 09 Sep 2008 22:15:57 GMT

@Alexnaldo Santos:

What you describe there seems to get rid of all the benefits of having typed objects in the first place (like type safety).

Also why would your "poco" objects know how to undo themselves? This sounds like a responsibility that should be elsewhere. Generally if I am doing this type of action I explicitly model my state transitions as commands which allows this to happen easily.

On the original topic, one of the most interesting bits of this for me would be in detaching an object from the current context and how that story would work.

I think macsgold has a good concept with allowing explicit registration for tracking, but let's stop calling these things entities and let's allow the registration of an [Aggregate Root] for the tracking of changes. Obviously when viewed as entities with bi-directional relationships etc the work involved with traversal can be quite expensive. The [Aggregate Root] pattern and the preference of uni-directional relationships (object paradigm vs relational paradigm) makes the search space significantly smaller.

A side note, dynamic proxies are scary for many users and one can quickly get to the "too much magic" point. In an ideal world the dynamic proxying would be transparent but it is unfortunately far from it at this point. Too many people expect (although they are writing terrible code) to be able to do things like if(obj.GetType() == typeof(Customer)) and the dynamic proxies will seriously confuse this type of developer.

EF here is running into an issue many others have run into. A run-time weave is what would be wanted but the limitations and confusing use of dynamic proxies is a less than transparent solution. There have been many of us who have been asking for a way to run-time instrument IL (other than the profiler API :)) to be built into the CLR. This would allow the run-time weave behavior being sought while maintaining a much better level of transparency to the developer.

re: Discussion about API changes necessary for POCO:

Harvey — Fri, 12 Dec 2008 03:28:50 GMT

In a DDD project, there will usually be s service object responsible for persist the domain object to the data store, such as UserSerivice.SaveUser(user) etc. So, why just let the consumer of the EF tell EF to persist the entity, no tracking, no comparison or notification. We just need something like _context.SaveObject(object), _context.DeleteObject(object) or _context.InsertObject(object). It is easy to implement and easy to use.

re: Discussion about API changes necessary for POCO:

Simon Segal — Sat, 03 Jan 2009 12:28:57 GMT

I would really love to see the equivalent of "Fetching Strategies" that appear in NHibernate. In following a DDD approach, POCO along with Fetching Strategies would allow me to inject and specify what my loading intentions are, whether they be to eager fetch of lazy load. I could today build some kind of interpreter perhaps that allows my Repository to build a chain of .Includes for eager fetching but lazy loading is currently extremely difficult to accommodate in this respect. Essentially what I would love to see is the ability to create single fetching strategies that embody my loading intentions either eager or lazy. For example in LINQ To SQL I was able to achieve this with eager loading in this fashion:

public interface IFetchingStrategy

{

/// <summary>

/// LINQ To SQL DataLoadOptions

/// to use on the given DataContext.

/// </summary>

DataLoadOptions LoadOptions { get; }

}

/// <summary>

/// Marker Interface

/// </summary>

/// <typeparam name="TRole">

/// Specification of a role for

/// dyanmic runtime type lookup.

/// </typeparam>

public interface IFetchingStrategy<TRole> : IFetchingStrategy{ }

THE IMPLEMENTATION:

public class CustomerLoyaltyDiscountFetchingStrategy : IFetchingStrategy<ICustomerLoyaltyDiscount>

{

private readonly DataLoadOptions _loadOptions;

#region IFetchingStrategy<Customer,ICustomerFaxChange> Members

/// <summary>

/// The DataLoadOptions used for

/// eager loading.

/// </summary>

public DataLoadOptions LoadOptions

{

get { return _loadOptions; }

}

#endregion

#region Constructor

/// <summary>

/// The constructor which sets the fetching strategies

/// eager loading options.

/// </summary>

public CustomerLoyaltyDiscountFetchingStrategy()

{

_loadOptions = new DataLoadOptions();

_loadOptions.LoadWith<Customer>(c => c.Orders);

_loadOptions.LoadWith<Order>(o => o.OrderLines);

}

#endregion

}

re: Discussion about API changes necessary for POCO:

Tanveer Badar — Tue, 03 Mar 2009 15:41:17 GMT

@Q1 and Q2: I think approach 1 of always giving correct results is the correct way to go forward with snapshots. It preserves existing code, provides correct results, seems like a win-win to me.

@Q3: Throwing an exception is just limiting the user even more. There won't be any choice except try{ } catch(blah b){ } around the whole thing.

Another approach would be to fail gracefully, populate an Errors collection instead.