Trasferisci entità appiattite anziché DTO?

1

Mi chiedo se l'idea sottostante abbia senso per la nostra applicazione web. Mostriamo vari elenchi di entità, che in genere si riferiscono ad altre entità e così via. Nella vista tabella, ci sono colonne che mostrano alcune proprietà dell'entità stessa (come e.name ) e anche delle entità collegate (come e.owner.email ).

Il modo classico è creare DTO contenenti tutte queste colonne e inviarle. Ciò significa che per ogni colonna aggiunta, è necessario apportare una modifica (banale) sul server. C'è anche un sacco di ridondanze, dato che molte entità collegate sono uguali. Ad esempio, e.owner è quasi sempre lo stesso, in quanto (con alcune eccezioni) tutti possono vedere solo le proprie entità.

Quindi la mia idea era di inviare entità JSONized, in cui i riferimenti vengono sostituiti dai loro ID e inoltre inviare un elenco delle entità referenziate. Tutto questo in modo ricorsivo, quindi per il grafico dell'oggetto

[
    {
        id: 101,
        name: "something1",
        company: {
            id: 201,
            name: "someCompany"
            owner: {
                id: 301,
                firstName: "Bart",
                lastName: "Simpson"
                email: "[email protected]",
            }
        }
    },
    {
        id: 102,
        name: "something1",
        company: {
            id: 201,
            name: "someCompany"
            owner: {
                id: 301,
                firstName: "Bart",
                lastName: "Simpson"
                email: "[email protected]",
            }
        }
    },
]

invece di

[
    {
        id: 101,
        name: "something1",
        company_name: "someCompany",
        company_owner_firstName: "Bart",
        company_owner_lastName: "Simpson",
        company_owner_email: "[email protected]",
    },
    {
        id: 102,
        name: "something2",
        company_name: "someCompany",
        company_owner_firstName: "Bart",
        company_owner_lastName: "Simpson",
        company_owner_email: "[email protected]",
    },
]

I'd send

{
    entities: [
        {
            id: 101,
            name: "something1",
            company: 201,
        },
        {
            id: 102,
            name: "something2",
            company: 201,
        }
    ],
    companies: [
        {
            id: 201,
            name: "someCompany"
            owner: 301,
        }
    ],
    owners: [
        {
            id: 301,
            firstName: "Bart",
            lastName: "Simpson"
            email: "[email protected]",
        }
    ],
}

e consente al cliente di ri-combinare le cose durante la visualizzazione del risultato. Ciò potrebbe portare a un buon risparmio della larghezza di banda (non visibile in questo piccolo esempio), ma probabilmente è ciò che Content-Encoding: gzip raggiunge comunque.

Il prossimo passo potrebbe essere la memorizzazione nella cache del client, in modo che vengano inviate solo le entità modificate e / o nuove. Questo potrebbe risparmiare molto di più. Il sovraccarico di implementazione è sicuramente non banale, ma sono sicuro che può essere fatto in un giorno o due.

Le mie domande:

  • C'è già qualcuno che sta facendo questo?
  • È una buona idea?
posta maaartinus 28.04.2016 - 18:46
fonte

1 risposta

2

Certamente si sta facendo, ma penso che l'idea buona dipenda dallo stile e dalle dimensioni dell'applicazione.

  1. In che modo grande è questa applicazione e per quanto tempo vivrà? È più difficile rintracciare comportamento e refactoring con un percorso molto lungo di codice che potrebbe fare affidamento sulle proprietà dell'oggetto e sulle relazioni, il che significa che deve essere ispezionato e corretto come un'unità. (Contrariamente ai livelli più sottili.)

  2. Quanto sei disposto a fidarti del cliente con dati grezzi? Quanto sono complicate le "regole sulla privacy" per rimuovere (o sostituire) le proprietà dell'oggetto che non dovrebbero essere visibili?

  3. Avrai sempre qualcosa che non si adatta al modello, come le pagine di elenco veloci ed efficienti. Non sarai in grado di adattare tutto a questo stile, quindi assicurati di stare tranquillo anche nel vecchio modo.

Penso che sia adatto per un'applicazione in cui stai spingendo lotti di logica al livello client / UI e ti fidi del client (e dell'utente) con la libertà di riscrivere e cambia qualunque sia il dato. Se fa parte di un'applicazione più grande, è "murato" dietro un qualche tipo di operazione di caricamento / salvataggio che applica altre logiche di business sul lato server.

Tuttavia, se stai lavorando su una grande applicazione che ha un sacco di regole lato server, allora avrei almeno un confine di traduzione molto chiaro tra "gli oggetti lato server" rispetto a "il grafico dell'oggetto JSON" ".

    
risposta data 28.04.2016 - 21:25
fonte

Leggi altre domande sui tag