I am planning an app which allows users to complete surveys/forms. I'm having trouble planning the data schema for the forms.

I really want to have a data structure which can be mostly automatically serialized and deserialized into classes.

I'm not sure where/how I should store answers either. I was thinking they could be some sort of dictionary or embedded in the question classes.

Functional Requirements

  • Questions can be added/edited/moved/removed (order is important)
  • Existing answers are preserved when questions are added are edited
  • Questions can be grouped (and even sub-grouped)
  • Groups can be repeat groups that can be answered a variable number of times
  • Responses can be PUT to the server as an incomplete update
  • Responses can be changed/updated/deleted

So I imagine I need some sort of data structure that allows me to do the following

  • address and get a specific element by some unique identifier
  • preserve order
  • insert a new element at a particular location
  • maintain a unique identifier so that answers recorded for previous versions of a form can be copied into an updated version
  • uniquely identify multiple sets of answers for a single repeat group


Here is some c# classes I've made to play with these concepts but they don't fulfill all the requirements

public class Form
    public Guid Id { get; set; }
    public string Title { get; set; }
    public List<FormElement> Elements { get; set; }

public abstract class FormElement
    public string Name { get; set; }
    public string Label { get; set; }

public class QuestionElement : FormElement
    public string Type { get; set; }
    public bool ReadOnly { get; set; } = false;

public class GroupElement : FormElement
    public List<FormElement> Elements { get; set; }

public class RepeatGroupElement : GroupElement



  • Asp.Net 5 Server (MVC 6) and Entity Framework 7
  • Java client app
    • I usually use Gson for serializing.
    • I'm also open to using any of the Guava collection classes but am not sure what the analogs in C# might be.

closed as too broad by Robert Harvey, Ixrec, user53019, gnat, Matthew Flynn Apr 16 '16 at 20:42

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.


There are two ways to go about designing an API. You can either design the objects and then build the API's contract from the objects, or you can design the API's contract and the build the objects to facilitate this.

In this case, you may find that going with the contract first design approach may be easier to work with. Side bit - glance at swagger as an approach to describing the contract for the REST (it looks like a REST API) endpoints.

Describe the JSON that you want to get back for each request or send with each request. And then build the objects that are going to be serialized and deseralized on each end (side bit, the swagger editor has code generation tools).

You want to change the order of two elements in a group? Ok, that could be a PATCH /formObject/1234 with the data [ { 'id':234, 'neworder':1, 'oldorder':10 } ] or something similar. And you document that and work on making the client and the server both adhere to that API contract.

The object first design also works. It also means that sometimes when realizing what you want the API to do later means going back to the drawing board for the object design.

Not the answer you're looking for? Browse other questions tagged or ask your own question.