This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
I have noticed in several places throughout the documentation that it is advised to only expose DTO's which (Lightspeed is quite happy to generate) over WCF services and not Lightspeed derived entities. I need to understand the underlying reason why this advice is given as my architecture prescribes the sharing of types which contain behaviors between the client and server pieces of our solution. I understand that this is not desireable in cases where interoperability is needed, but there are a large number of WCF services that will exist only to further the 'distributed reach' of our client where interoperability is not an issue. Is the reason that this advice is given based on principle or is it something more concrete - like serializing Lightspeed entities is ridiculously computationally expensive or that they are too fat on the wire to be efficient? |
|
|
Hi Aaron, The advice is given based on principle for building interoperable connected systems - LightSpeed entities can be serialized over the wire - which you will likely want to do if you are simply remoting your entities. We would suggest you only serialize the entities themselves and not walk the relationship graph since you may end up with unneccesarily large payloads. e.g. If you use the DataContract formatter (WCF), I would suggest you only mark up the value fields as forming part of the contract to avoid running into this. Let us know if you have any questions in this area :)
Jeremy |
|
|
Hi Mindscape Team, i know this is a very old forum i am posting on, i just have one issue with LIghtspeed entities here, i am using WCF services and my architecture and model forces me to expose the Serialized Lightspeed entity with all data members. i love lightspeed for its support for custom attributes where i jsut specified the DataMember attribute to get this done and this worked like a charm. even for the related entities i did the same and i am able to access the related entities.
now there are two major issues with this are 1. i have to define the same custom attribute for all my fields, is there a way to configure it as default for all the fields so i do not have to write it everytime for every single field as its very hectic job. 2. this is a major one, i want to specify the custom attribute for the ID column as well which does not seem to be having any option on the light speed designer, i need the identity to be serialized as i need the ID to be sent to the client, Imagine a web form having an entity with no ID.
what is the resolution for this?? i am using Lightspeed 3.11 with Visual Studio 2010.
Regards, Aakif Hassan
|
|
|
It's not possible to automatically apply an attribute to every field. You could edit the entity templates to add DataMemberAttribute directly into the field/property template, but this won't help with the Id field. You *might* be able to use the TypeDescriptor system to add an attribute to the LightSpeed-defined Id field but I'm not sure if WCF respects type descriptors. If you use data transfer objects instead of exposing raw entities then these will take care of adding the DataMemberAttribute for you. Designer-generated DTOs don't serialise the ID field automatically but you can add this via partial classes and partial methods. |
|
|
thanks for the reply Ivan :). yes, i used the entity templates for this purpose, but i was also able to apply attributes one by one and get it worked but as i said it was hectic. regarding ID, even if you use type descriptor, WCF may not respect it, where the only reason is serialization over the services, which requires a property to be GET and SET both, where as ID cannot be set even by using Type Descriptor. what we did is to define our own property and came up with a mechanism to use LightSpeed Id property for get and for set use our own variable so updates across the service should work fine, and this solution perfectly worked :). i wish i could have used DTOs but our design architecture does not some how support them to a high extent and our model is already utilizing the entities efficiently. this was the only issue and now it got resolved. Thanks :) |
|