angular - DRY-prinsippet: Angular2/Typescript og Java back-end objektduplisering

Jeg er en Java-utvikler, men jeg har nylig begynt å lære Angular2/Typescript. Jeg har jobbet med Angular 1.x før, så jeg er ikke helt nybegynner :)

Mens jeg jobbet med en POC med en RESTful Spring Boot-backend og Angular2-frontend, la jeg merke til at jeg dupliserte modellobjekter på begge sider mye, f.eks.

Java-objekt

public class Car {
    private Double numSeats;
    private Double numDoors;
    .....
}

Nå, i interesse for Typescript og å være sterkt typet, ville jeg laget et lignende objekt i prosjektet mitt på frontend:

export interface PersonalDetailsVO {
    numSeats : number;
    numDoors : number;
}

Jeg dupliserer arbeidet og bryter stadig prinsippet om DRY (Don’t Repeat Yourself) her.

Jeg lurer på om det finnes en bedre måte å gjøre dette på. Jeg tenkte på kodegenereringsverktøy som jSweet, men er interessert i å høre om noen andre har støtt på det samme problemet og hvordan de tilnærmet seg det.

Svar #1

Det finnes to skoler for tankegang om hvorvidt dette er et brudd på DRY-prinsippet. Hvis du er virkelig, virkelig sikker på at det finnes en naturlig kobling du alltid ville brukt for å binde JSON i hvert språk, kan du si at det er duplisert arbeid; noe som er (i det minste delvis) tankegangen bak IDL-type språk i teknologier som CORBA (men jeg viser alderen min).

PÅ DEN ANDRE SIDEN bør kanskje hvert system (serveren, klienten, en alternativ klient hvis noen skulle skrive en) være fritt til uavhengig å definere de interne representasjonene av objekter som passer best for det systemet (gitt dets språk, hva det planlegger å gjøre, osv.).

I ditt eksempel inneholder typescriptet absolutt ikke all informasjon som trengs for å definere Java-"ekvivalenten". ('number' kan kartlegges til mange ting; og typescriptet sier ingenting om tilgangsmodifikatorer...) Selvfølgelig kan du begrense det ved å adoptere konvensjoner, men poenget mitt er at det ikke er åpenbart at det ville være en 1-til-1-mapping.

Kanskje ett språk håndterer referanser mer elegant enn et annet. Kanskje ett ikke kan håndtere sirkulære referanser, men det andre kan. Kanskje ett har grunn til å foretrekke en mer flat fremstilling av objektet. Kanskje mange ting.

Alt det sagt, er det absolutt sant at hvis du endrer json-strukturen til et objekt, og du opprettholder hver systemets interne representasjon uavhengig, så må du sannsynligvis gjøre kodeendringer på flere steder for å tilpasse den ene underliggende endringen. Og pragmatisk, hvis det kan unngås, er det en god ting.

Så hvis du kan komme opp med en kodegenerator som behandler den mer uttrykksfulle språkets representasjon for å lage en representasjon for det mindre uttrykksfulle språket, og kanskje i det minste bruke det som standard, kan du finne ut at det ikke er en dårlig ting for prosjektet ditt.