Client REST process response in JSON without knowing domain objects

1

I'm doing a RESTFull server with Spring MVC, the controller only returns JSON, until then blz, would my client know nothing of the domain classes and still process the requests?

I was thinking of turning JSON into an object as if it were a database table, hence I could manipulate the data, such as columns and values.

The fact is that I do not want my client to know any domain class, it just receives the information, processes, and shows the user, the user makes the changes and sends.

I created a class called DataSet, the goal is to manipulate data as if it were a table in a generic way.

example

    DataSet dataset = new DataSet();

    //Pode importar a partir de um pojo
    /*dataset.fromPOJO(customerObject);
    dataset.fromJSON(JSONString);
    dataset.fromCSV(CSV);*/

    dataset.setDataSource(datasource);
    dataset.setTableName("Clientes");
    dataset.setLimit(100);
    dataset.setFetchRows(100);

    dataset.getFields().add(new Field("Nome", FieldType.STRING, 100) );
    dataset.getFields().add(new Field("DataNascimento", FieldType.DATE));
    dataset.getFields().add(new Field("DataHoraCadastro", FieldType.DATETIME));
    dataset.getFields().add(new Field("Foto", FieldType.BINARY));
    dataset.getFields().add(new Field("Credito", FieldType.DOUBLE, 2));
    dataset.getFields().add(new Field("Vendedor", FieldType.LOOKUP, "TABELA_PESSOA", new String[]{"id"}, new String[]{"id_vendedor"}));
    dataset.getFields().add(new Field("Contatos", FieldType.DETAIL, "PESSOA_CONTATO", new String[]{"pessoa_id"}, new String[]{"id"} ));


    //Adicionando registro
    dataset.append();       
    dataset.getField("Nome").setValue("RODRIGO RODRIGUES DA COSTA");
    dataset.getField("DataNascimento").setValue("06/04/1985");
    dataset.getField("Credito").setValue(1765.87);      
    dataset.post();

    dataset.append();
    dataset.getField("Nome").setValue("MARIA CECILIA CABRAL RODRIGUES");
    dataset.getField("DataNascimento").setValue("11/03/2011");
    dataset.getField("Credito").setValue(333);      
    dataset.post();

    System.out.println("Mostrando uma quanitdade de "+dataset.getRecordCount() );
    //Monstrando todos os registros
    for (Record record : dataset.getRecords()) {
        System.out.println("Registro número "+record.getIndex() );
        System.out.println(record.getField("Nome").getValue() );
        System.out.println(record.getField("DataNascimento").getValue() );
    }

I ask, have you any other way to do this? I do not want my client to know the existence of the domain class, so with the DataSet in my view it works, now has it another way?

    
asked by anonymous 31.01.2014 / 01:25

1 answer

2

Let's simplify?

Why do not you apply the concept of KISS? Keep It Simple Stupid! I always try to apply this to my projects.

If you do not want to expose your domain classes why do not you do something like:

public class AtualizarClienteVO{
    String nome;
    Date aniversario;
    // etc
}

And in your domain you would have:

public class Pessoa{
    String nome;
    Date aniversario;
    // etc
}

It would just do after person.setName (updateClientVO.getName) and that's it. Your model is protected.

Is this good practice?

It is a common practice to have an object that will serve only to carry the data (usually known as VO, DTO). At the same time you keep your domain hidden.

Do not try something too complex where you would have little gain. [=

In the above way you would be mapping just the screen data to any object and then you parse it for your model.

Conclusion

I see this approach as good practice because:

  • You will keep your domain / VIEW decoupled. I already had enough experience between making changes in the domain and not having to change the VOs
  • You can reuse View objects in other projects. If you have another view, it will be able to configure specific view only things in VOS, it will not affect your domain
  • Creating a bizarre type of entity to protect your domain will only make it more difficult to maintain later. Make your classes easy to read and easy to use.
  • 31.01.2014 / 01:45