Shh... IT in progress.

State of ObjectLayer

User Rating: / 0
PoorBest 

OK, well as you probably are aware I have been researching the ObjectLayer for my commercial application which is currently using the serialization of IDataStoreover WCF.

The aim is to blog about how to achieve certain things using the ObjectLayer, however at this stage, I don’t have anything to report other than I found a brick wall that I am working on how to get over

I have made a few suggestions and have a question with DX.

http://www.devexpress.com/Support/Center/Issues/ViewIssue.aspx?issueid=S137942

http://www.devexpress.com/Support/Center/Issues/ViewIssue.aspx?issueid=S137919 (example app attached)

http://www.devexpress.com/Support/Center/Issues/ViewIssue.aspx?issueid=Q335685

The scenario I want to support is being able to roll a Auditing system out of the Server and also have the ability on the server side to “blank” fields.

I believe with the current implementation I could achieve the “Blanking” fields, by checking the ClassInfo’s wtihin the LoadObjects method and blanking the appropriate field, then on the CommitObject checking again for that ClassInfo and setting the Changed property for that field’s index to False, this seems to stop the persistence of the field.

However the auditing doesn’t appear possible at the moment due to the GetPropertiesListForUpdateInsert not being called by the SerializableObjectLayer, therefore when the CommitObjects on the server side receives the request not only does it receive all values regardless if they have changed or not, but the Changed[] collection doesn’t indicated what fields actually changed, as when the Helper sets all the values of the XPObjectStub it is setting the Changed flag to true.

The problem is the helper is an internal class within the XPO Library so there is no way that I can see to override this behaviour.

Obviously DX wants these scenarios to work so I would imagine there will be a workaround or an improvement in future versions, but as it stands right now I can’t find a way around it.

Another point I will make which I am not 100% happy with is how the XPObjectStub is serialized, currently it includes the Member definitions for the Class, now if you loaded 100 rows you would end up with 100 definitions being sent even if it is 100 rows of the same class. I personally don’t feel this is a good scenario, I can’t understand why we can’t just rely on the ClassInfo’s information on either end (usually we use the same Data library on both ends) so the class definitions are the same on each end. Will keep you posted.

My questions are still being “investigated” so will wait and see what reply I get and update you people following this blog.