Progettazione XML - confuso tra attributi ed elementi [chiuso]

Question

Progettazione XML - confuso tra attributi ed elementi [chiuso]

#1 da (3 voti)

-1

Devo progettare una struttura xml per impostare lo scambio di dati standard con il mio cliente.

Ci occupiamo dei pagamenti e dei relativi dati.

Al momento, i miei dati XML hanno questo aspetto:

<PAYMENTS>
 <CURRENCY>DOLLARS</CURRENCY>
 <PAYMENTTYPE>CHEQUE</PAYMENTTYPE>
 <PAYMENT>
   <AMOUNT>100</AMOUNT>
   // ALL OTHER DETAILS GO HERE
 </PAYMENT>
 <PAYMENT>
   <AMOUNT>100</AMOUNT>
   // ALL OTHER DETAILS GO HERE
 </PAYMENT>
</PAYMENTS>

Ma uno dei miei colleghi è riuscito a scrivere una versione diversa.

<PAYMENTS CURRENCY = DOLLARS 
          PAYMENTTYPE = CHEQUE>
 <PAYMENT>
   <AMOUNT>100</AMOUNT>
   // ALL OTHER DETAILS GO HERE
 </PAYMENT>
 <PAYMENT>
   <AMOUNT>100</AMOUNT>
   // ALL OTHER DETAILS GO HERE
 </PAYMENT>
</PAYMENTS>

(I tag currency e paymenttype vengono spostati come attributi perché non si ripeteranno di nuovo come payment )

Ma mi chiedo quale sia il metodo migliore per rappresentarlo? La mia strada o la seconda?

Ci sono delle linee guida per questo?

(Non sono sicuro se questo aiuti: Ma, sto usando C # per la codifica)

scheme c# .net xml

posta now he who must not be named. 28.04.2014 - 08:53

fonte

1 risposta

Leggi altre domande sui tag scheme c# .net xml

Metodo valido per condividere il nostro progetto PHP [duplicato] Come viene memorizzato il software di sistema sul computer? [chiuso]

score 3 · Accepted Answer

Benvenuti nel problema numero uno dell'uso di XML come formato di serializzazione dei dati! Attributi vs elementi contenuti - così utile nel markup, così fastidioso nella serializzazione dei dati ...

In ogni caso, supponendo che tu sia obbligato ad andare con la mandria e usare XML per la serializzazione dei dati, ci sono solo tre ragioni per preferire gli attributi sugli elementi:

Se il campo ha i suoi sottocampi.
Se il campo può essere ripetuto.
Se il campo è qualcosa che desideri trattare come heredoc .

Tutti questi casi si applicano al design, non al set di dati di esempio che hai in mano. Se un campo nei tuoi dati non segue alcuna di queste regole, ma il design consente a una delle regole di applicarlo, dovrebbe essere un elemento.

Il motivo per preferire gli attributi sugli elementi (a meno che non si applichi uno dei casi) è che anche con LINQ su XML è molto più facile usare gli attributi. I linguaggi di programmazione di solito rendono più facile dire "Ho un oggetto, darmi il contenuto di uno dei suoi campi" piuttosto che dire "Ecco una pila di oggetti, prendetene uno che soddisfi determinati criteri".

Sia CURRENCY che PAYMENTTYPE sono - come dici tu - non ripetibili per design, e non sono composti, e non hanno davvero bisogno di essere heredoc - quindi dovrebbero essere, con ogni mezzo, attributi . Quindi, dovrebbe essere, tra l'altro, AMOUNT di PAYMENT , quindi dovresti scrivere:

<PAYMENTS CURRENCY = "DOLLARS"
    PAYMENTTYPE = "CHEQUE">
    <PAYMENT AMOUNT="100">
        // ALL OTHER DETAILS GO HERE
    </PAYMENT>
    <PAYMENT AMOUNT="100">
        // ALL OTHER DETAILS GO HERE
    </PAYMENT>
</PAYMENTS>

e considera quale di questi "TUTTI GLI ALTRI DETTAGLI" dovrebbe in realtà "ANDARE QUI" e quali dovrebbero essere anche gli attributi.