Hi,

I've been using LLBLGen for a while now and have always used DTOs to pass over the wire. This decision was made pretty early on and it is only recently that I have performed some serialization tests. The test revealed to me just how good the serialization is for LLBLGen Entities especially with the FastSerialization option.

I now have a new project and one requirement is change tracking within the UI for which I will need to edit the DTO generation templates. This seams like reinventing the wheel to me so I would like to use the entities themselves.

I set-up some tests and am more than happy with the performance and size of the objects the problem I have is that I must be able to support multiple versions of the client application, with the DTOs this is fine or at least is possible given a little forethought. I made a test where I added a field to an entity and tried to retrieve the entity from a client that had the old entity model and thus knows nothing about the newly added field. As expected this resulted in a error from the LLBLGen serialization, my question is how I can get this to work.

In the DTO templates we would add [OptionalField] for any fields that are added is there an equivalent attribute that will work with the LLBLGen implementation?

Any help is appreciated.

Thanks

Oliver

The best would be that the clients would be up-to-date, many things about the service functionality relays on new fields anyway.

Now, the OptionalField specifies that a field can be missing from a serialization stream, this is .net code. I don't know how it will work due to the WCF data contracts, you should give it a spin.

What about your DTO's? I didn't understand why you want to drop them and tkae the entities instead.

Hi daelmo,

The best would be that the clients would be up-to-date, many things about the service functionality relays on new fields anyway.

I agree but unfortunately I cannot force users to take the latest version of the client each time there is a change. For some changes this is unavoidable but in general it is possible to avoid the situation.

Now, the OptionalField specifies that a field can be missing from a serialization stream, this is .net code. I don't know how it will work due to the WCF data contracts, you should give it a spin.

The OptionalFieldAttribute works fine with DataContracts over WCF and this is the one of the techniques we have used in previous projects to offer backward compatitibility. The question I have is whether this can be applied to an entity field and if so where should place the attribute? I know that LLBLGen uses its own serialization and therefore I was unsure about what to put where.

What about your DTO's? I didn't understand why you want to drop them and take the entities instead.

I'm not entirely sure I do to be honest, the key requirement that got me thinking about using the entities is that the client application must track changes to the objects to which it is bound. Users need to be aware of the changes that they have made and in certain circumstance must review these changes before submitting. I could add change tracking to the DTO's (Not quite sure how yet ) but if the entities are small enough and can offer backward compatibility then I they may be the better option.

Thanks

Oliver

Is there anyone out there that can help with this question?

I need to be able to identify an entityfield as optional so that WCF deserialization does not throw an error if the client version of the entity does not include the field.

Please let me know if you have any ideas

optional elements aren't supported in webservices / services architectures for the simple reason that the element type to instantiate is fixed at deserialization. So you can't have, based on data, type X or type Y, it's always either X or Y.

That's also the problem with services: versioning. If you add elements to a service, you have to version the service to a new version and update the client to use the new service version.

(I presume you're not talking about a nullable field)