angular - DRY-principen: Angular2/Typescript och Java back-end objektduplication

Jag är en Java-utvecklare men jag har nyligen börjat lära mig Angular2/Typescript. Jag har arbetat med Angular 1.x tidigare så jag är inte en total nybörjare :)

När jag arbetade med en POC med en RESTful Spring Boot-backend och Angular2-frontend märkte jag att jag duplicerade modellobjekt på båda sidor ofta, t.ex.

Java-objekt

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

Nu, i intresset av Typescript och att vara starkt typad, skulle jag skapa ett liknande objekt inom mitt front-end-projekt:

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

Jag duplicerar arbetet och bryter ständigt mot DRY-principen (Don’t Repeat Yourself) här.

Jag undrar om det finns ett bättre sätt att göra detta på. Jag funderade på kodgenereringsverktyg som jSweet men är nyfiken på att höra om någon annan har stött på samma problem och hur de gick tillväga.

Svar #1

Det finns två skolor när det gäller huruvida detta är ett brott mot DRY-principen. Om du är verkligen, verkligen säker på att det finns en naturlig avbildning som du alltid skulle använda för att binda JSON i varje språk, då skulle du kunna säga att det är duplicerat arbete; vilket är (åtminstone delvis) tanken bakom IDL-typ-språk i teknologier som CORBA (men jag visar min ålder).

Å andra sidan kanske varje system (servern, klienten, en alternativ klient om någon skulle skriva en) bör vara fritt att oberoende definiera de interna representationerna av objekt som är bäst lämpade för det systemet (givet dess språk, vad det planerar att göra, etc.).

I ditt exempel innehåller typescripten definitivt inte all information som behövs för att definiera Java-"ekvivalenten". ('number' kan mappas till många saker; och typescripten säger inget om åtkomstmodifierare...) Självklart kan du begränsa det genom att anta konventioner, men min poäng är att det inte är självklart att det skulle finnas en 1-till-1-mappning.

Kanske hanterar ett språk referenser mer smidigt än ett annat. Kanske kan ett inte hantera cirkulära referenser men det andra kan. Kanske finns det skäl att föredra en mer platt vy av objektet. Kanske många saker.

Allt detta sagt, är det verkligen sant att om du ändrar json-strukturen för ett objekt, och du underhåller varje systems interna representation oberoende, då måste du sannolikt göra kodändringar på flera ställen för att anpassa dig till den enda underliggande förändringen. Och pragmatiskt, om det kan undvikas är det en bra sak.

Så om du kan komma på en kodgenerator som bearbetar den mer uttrycksfulla språkets representation för att skapa en representation för det mindre uttrycksfulla språket, och kanske åtminstone använder det som standard, kan du upptäcka att det inte är en dålig sak för ditt projekt.