ive been dealing with webservices lately and i notice the XML the entities output as a lot of redudant data in it that could be slimmed down, mainly in the Fields arena.. when i pass an entity across web services this is what i get for the fields collection...

                        <Fields>
                          <Id>
                            <CurrentValue>d3f35b4f-1da4-453e-ae74-17dcbaa923d0</CurrentValue>
                            <DbValue>d3f35b4f-1da4-453e-ae74-17dcbaa923d0</DbValue>
                            <IsChanged>False</IsChanged>
                            <IsNull>False</IsNull>
                          </Id>
                          <PermissionCode>
                            <CurrentValue>USERGROUP_MODIFY</CurrentValue>
                            <DbValue>USERGROUP_MODIFY</DbValue>
                            <IsChanged>False</IsChanged>
                            <IsNull>False</IsNull>
                          </PermissionCode>
                          <UserId>
                            <CurrentValue>19556ba7-4deb-4498-a8ec-098e5b536188</CurrentValue>
                            <DbValue>19556ba7-4deb-4498-a8ec-098e5b536188</DbValue>
                            <IsChanged>False</IsChanged>
                            <IsNull>False</IsNull>
                          </UserId>
                          <CreatedDate>
                            <CurrentValue>2005-11-10T14:26:39.1870000-07:00</CurrentValue>
                            <DbValue>2005-11-10T14:26:39.1870000-07:00</DbValue>
                            <IsChanged>False</IsChanged>
                            <IsNull>False</IsNull>
                          </CreatedDate>
                          <ModifiedDate>
                            <CurrentValue>2005-11-10T14:26:39.1870000-07:00</CurrentValue>
                            <DbValue>2005-11-10T14:26:39.1870000-07:00</DbValue>
                            <IsChanged>False</IsChanged>
                            <IsNull>False</IsNull>
                          </ModifiedDate>
                        </Fields>

Notice that ischanged and isnull is almost always false. Why not default ischanged and isnull to false and just not include them in the xml output when they are this value?

Same thing with dbValue, why not defualt it to the same as the current value. As i have some pretty large fields and its seems like such a waste transporting the same value twice over the wire...especially when these values are from TEXT fields in the db that well contain A LOT of text

In my situation like 95% of the time, isnull and ischanged is false, and the dbvalue is the same as the current.

Now you prolly have a good reason for doing it the way you did, but i cant see the need for it when using webservices so is it possible to get a "webservice aspect" like the compact xml aspect or whatever. I can then modifiy my webservicehelper template to call the write/readxml with the webservice aspect.

I assume you've already read these two pages in the LLBLGen User Manual, but in case you haven't, they speak directly to the use of LLBLGen with WebServices and XML:

Generated code - XML Support (serialization, de-serialization), Adapter Generated code - XML Webservices support

Serializing any object via XML is going to be verbose. Everything in the object must be described in detail to enable the object to be reconstructed on the other end.

Suggestions: 1. Use the adapter model 2. Consider serializing a different object if the client does't "need" the benefits of the full entity object.

There's no way to tap into the xml serialization for webservices, i.e.: it's started by .NET, so it's in the format the code produces. The format is like this because it is usable for change tracking. You can grab an entity from a webservice, modify it in the client and send it back and all is good.

There's no way to tap into the xml serialization for webservices, i.e.: it's started by .NET, so it's in the format the code produces.

Your entites implement IXmlSerializable so your the one who is producing the XML .NET calls writexml when sending and readxml when recieving.

I've looked in the ORMSupportClass source code so i know how its being produced. Its in the EntityField2.cs class under the writeXml method. I dont see a way of overriding what that method is producing though without modifiy the ORMSupportClass code and compliling my own version.

I know, I wasn't very clear in my answer I think .

What I meant was that if you have a webmethod, and return an entity, you can't specify somewhere HOW the XML is produced, there's only one method. So, an alternative would be if you set a property of the entity prior to returning it from the webmethod and that property then affects the xml production. (I think that's the only 'solution' to this. ).

Well there is a couple options...

1) You create a new xml aspect called "webservices" and change the writexml method in the entityfield class to use defaults.

2) i do the same thing as #2 but only i get to enjoy it and i now have to reedit and recompile each time you fix a bug etc in the ORMSupport library.

3) Implement IXmlSerializable explicitly for each entity, copy and modify the entitytoxml and xmltoentity code from entitybase2.cs and implement the readxml and writexml methods myself. This could be done in the "webServiceHelper" template thats generated using my webservice templates.

When i first posted, i hadnt thought of option #3. So option #1 was the only solutioni could think of since in my opinion option #2 isn't an option.

I still think option #1 is best

By using a default you could slim the xml down to

                        <Fields>
                          <Id>
                            <CurrentValue>d3f35b4f-1da4-453e-ae74-17dcbaa923d0</CurrentValue>
                          </Id>
                          <PermissionCode>
                            <CurrentValue>USERGROUP_MODIFY</CurrentValue>
                          </PermissionCode>
                          <UserId>
                            <CurrentValue>19556ba7-4deb-4498-a8ec-098e5b536188</CurrentValue>
                          </UserId>
                          <CreatedDate>
                            <CurrentValue>2005-11-10T14:26:39.1870000-07:00</CurrentValue>
                          </CreatedDate>
                          <ModifiedDate>
                            <CurrentValue>2005-11-10T14:26:39.1870000-07:00</CurrentValue>
                          </ModifiedDate>
                        </Fields>

If you modfied a row or two it would look like this

                        <Fields>
                          <Id>
                            <CurrentValue>d3f35b4f-1da4-453e-ae74-17dcbaa923d0</CurrentValue>
                          </Id>
                          <PermissionCode>
                            <CurrentValue>USERGROUP_MODIFY 1234567890</CurrentValue>
                            <DbValue>USERGROUP_MODIFY</DbValue>
                            <IsChanged>True</IsChanged>
                          </PermissionCode>
                          <UserId>
                            <CurrentValue>19556ba7-4deb-4498-a8ec-098e5b536188</CurrentValue>
                          </UserId>
                          <CreatedDate>
                            <CurrentValue>2005-11-10T14:26:39.1870000-07:00</CurrentValue>
                          </CreatedDate>
                          <ModifiedDate>
                            <CurrentValue>2005-11-10T14:26:39.1870000-07:00</CurrentValue>
                          </ModifiedDate>
                        </Fields>

Granted in this example its not a lot in savings, but say your returning 20 or so entities, it adds up! Especially when you have TEXT fields in the DB that can be very large.