User defined fields

Topics: General Discussion Forum, July and December Releases Forum
Jul 13, 2007 at 12:06 AM
I'm using the Web Service Software Factory to create a WCF application in C#. Our application need to allow the user to create user defined fields and tables. Does anyone have any suggestions on how to do this? I know that I can use reflection (or something similar to read the tables. But then how do I load them into the entities? How do I pass them to the client?

Any help would be appreciated.


Jul 13, 2007 at 7:01 PM
Todd, I'm not sure I understand the requirement. Is your question how to design the messages to support unknown field names and values? If you could be a little more specific about the data passing to and from the service consumers, I think the community and the Service Factory team could be more help. Thanks,

Jul 13, 2007 at 10:56 PM
Yes, I'm asking: "How to design the messages to support unknown field names, types and values?" Also how do I design the Entities that the Guidance Package created to support unknown field names, types and values? But the second question may be better asked in the Data Access Application Block forum.

Thanks for your help.

Jul 20, 2007 at 8:47 PM
Hi Todd,

I believe that the solution you are asking for is very dependent on the actual requirements you have and on how deep you want to go in their implementation. The simplest requiremet is just having extended user-defined properties within business objects/entities. One of the hardest is when user defines totally his own entities. The second very important question is how this data is supposed to be used later. The first situation is when users just fill in this data and later it can be only shown to the others, so your application "doesn't know" what user fills and what the others see. The second is when your business processes should work with this data.

Answering straight to your question - there is no way to transfer unknown entities because entities should be strongly typed (at least have interface), but you can send extended properties as a dictionary - key/value pairs as property name/property value pairs. So it's possible to go with very abstract design : you have a base entity object which have only a couple of predefined fields, like Guid and entity type (strong type or type id), all the others are extended. In database you store data in Xml. But this solution is very expensive in terms of performance.

If you need only extended properties you can serialize them to string and save into a single table coulumn (take ASP.NET 2.0 Profile properties as a sample). If you are using SQL Server 2005 you can use XML data type for that.

If your entities are used only to input data and display it I'd recomment to try Office Infopath forms. It turned out that Infopath is cheaper solution then custom implementation of object-relation and object-presentation mappings.

Jul 24, 2007 at 7:14 PM
Edited Jul 24, 2007 at 7:27 PM

I asked this user-defined / object extension scenario already in GotDotNet time but unfortunately cannot access this thread any longer. The main question here is how to support data/message contract extensions without affecting ‘agreed data/message contract’.

This scenario is often required in following cases:
• Software house writes custom or commercial product. The product must support end-customer's to be able to extent the agreed data/message contract.

Data Element... (Maintained by software house)
Data Element...
Data Element...
Data Element... (Maintained by end-customer extension module)
Data Element...
Data Element...

• Data contracts in large worldwide organizations may use smaller canonical data contract and extend the canonical data contract with continent specific data elements. For example typical case would be US-Address and EU-Address. For example:

Data Element... (Logic only available when configuration of the software is USCONTINENTSPECIFIC_BLOCK)
Data Element...


Data Element... (Logic only available when configuration of the software is EUCONTINENTSPECIFIC_BLOCK)
Data Element...


• In period of time, fixed data contract must be extended by using xml data types within agreed data contract. For example, new integreated inhouse software would need extent Customer data/message contract but Customer data contract would like be kept same and allow the extension inside the specific xml structure like:

Data Element... (Maintained by outsourced Party A)
Data Element...
...Data Element (Maintained by outsourced Party B)
...Data Element

I see only one feasible way out on this issue and that is to support xml data type in message contracts. Also this should be supported as discussed in work item 323.

Hope this clears the issue....