Feature suggestion: Client side entity manager

[weitzhandler]

Suggestion

Back in the days of Silverlight, we had the beloved RIA Services that provided a full-blown client entity manager.

My request is that now with OData's comeback, and especially with the sunset of WCF and the development of RESTier, the client-side OData support should be expanded to encapsulate a full blown entity repository that interacts with the server, that provides internal URL generation, entity querying, change tracking, and manipulation of an entire graph, and be extensible to validation, caching, logging, and more, with most of the features are already offered with OData.

Most of what I'm asking is already provided by Simple.OData.Client, but:

• It seems to be a bit out of maintenance - I wish MS would dedicate some resources to boost it up
• It was built before DI was ruling, and as such, isn't extensible enough, it would really benefit if the settings, and the various JSON parsers and query generators could have been intercepted and extended.

Useful related repos (some of them no longer active):

• Simple.OData.Client
• Microsoft.OData.Client
• Breeze#
• TrackableEntities
• TrackerDog
• Refit
• Fody.PropertyChanged

Here are some .NET Standard interfaces to be considered as implementation by the the client side entities, either on code generation, or via code injection (Fody, code emit, proxy classes etc.). All in .NET Standard 2.0.

• IRevertibleChangeTracking
• INotifyDataErrorInfo
• IEditableObject
• INotifyPropertyChanging
• INotifyPropertyChanged

For navigation collections, these interfaces should be considered:

• ICancelAddNew
• INotifyCollectionChanged

It should act like a client side Repository / Unit of Work, that takes care of all entity management business.

Related: dotnet/efcore#5536
Related: OData/RESTier#616

[NetTecture]

PLEASE do not. I start getting used to the state of the odata clients - but the question is what you would even consider a client. Even assuming netstandard 2.1 (which is problematic - simple.odata.client is not working at the moment in blazor, i.e. browser side razor), I deal regualrly with 2-3 different clietns.

While having a rule them all client would be nice, I rather rely on self writte nby now clients - because you nicely forgot things like Typescript (which are used a lot). And most of my projects do not need an IEditableObject or any notification - i merge the dto into way more specilized front end views at high speed, and pelase with low overhead.

[weitzhandler]

Simple.OData.Client is good enough, it's just not made for extensibility, and noo proper DI support.
Had it been extensible enough, and we could have built caching/validation/change tracking on top of it.

I rather rely on self writte nby now clients

Amazing. I envy you. But I think for such an undertaking feature, a community driven project has better chances to succeed.

And most of my projects do not need an IEditableObject or any notification

These were merely suggestions for optional interfaces to implement, that can potentially make change-tracking (to get notified for dirty objects) easier.

[NetTecture]

Simple.OData.Client is good enough,

I acutally am working on yet another generator for C# taht will use simple odata client internally. My main complaint with it is that ist is TOO flexible. Lots of magic strings or assumed knowledge - which means that a change in the API (which happens when you develop client and bavkend at the same time) does not lead to compiler errors but runtime errors. I prefer the later - parameter name change? Please regenerate proxy classes and compile error ;)

Amazing. I envy you.

I do not. This is as much from a total lack of anything resembling a good client in many areas. Mine have serious issues at times, but they do work with generated code and handle what we do use extensively, which inclues "arcane" features such as functions and actions, or allowing multiple API endpoints (i.e. odata $metadata on different url's with different content - i.e. a client connecting to 2-3 backend API). The later soudns like a joke, but I know some clients having problems with that ;) My lack list is as bad as any other, but it does what I need to get done. And most i.e.Typescript clients have a much more limited feature set, sadly.

This IS a mess - i think odata is as much indered by the quality of the c# implementation (which is like a leaking sieve - ignoring the dotnetcore 3.0 issue there are a TON of lacking features, check the roadmap) as it is by teh total lack of professionally usable clients in various environments.

Last time we moved some Java android code to odata - what I do in 5 lines in Simple.Odata.Client was PAGES of code for the java client (apache olingo).

[weitzhandler]

This IS a mess

I know. That is why I opened this issue in the first place. This should be a community project, not a one man's work.

[robertmclaws]

Gents, I know there is some unrest about the state of OData. But can everyone please keep it constructive? You folks have to remember that OData was invented with .NET Framework 2.0 in 2007. There's a lot of legacy code, and a lot of stuff that doesn't work in modern codebases. The teams are working on that. There's no need to take a verbal dump on everyone, and complaints about other OData vendors belong in those vendor's feedback channels.

Now, back to the topic at hand: If we're looking at features for a client-side entity manager, my vote would be no. In my opinion, the juice is not worth the squeeze. It adds way too much architectural complexity for not a lot of payoff.

Now that Entity Framework 6.3 is .NET Standard 2.1 compliant (which means it can run on the client), you'd probably be better off writing an Entity Framework (or EFCore) provider for OData than making the team roll their own change tracker, which is far easier to get wrong than get right.

However, code generation SHOULD emit bindable objects, which means, at minimum, implementing INPChanged. It should use ObservableCollections instead of Lists, so you get the benefit of CollectionChanged events. And it should let you omit proxy generation if you already have your own objects, so you don't have more than one type of the same object in your codebase.

Just my $0.02.

[weitzhandler]

Well according to this comment, it looks like the OData team has targeted this issue by giving lots of love to the OData Connected Service. New commits and releases are released very often and the repo team seems to be responsive, so welcome back OData client!