Spazio dei nomi della società nelle applicazioni web

Question

Spazio dei nomi della società nelle applicazioni web

#1 da (3 voti)
#2 da (0 voti)
#3 da (0 voti)

3

La maggior parte delle (buone) convenzioni dello spazio dei nomi richiedono uno spazio dei nomi con nome di società.

es

CompanyName.ComponentName.x.y.z

Quanto bene questo si traduce nelle applicazioni web? In molti siti Web, la società è indicata dal nome del sito Web (ad esempio, Facebook, MySpace). Questo convoglia lo spazio dei nomi, facendoli apparire come se fossero applicabili solo a un singolo progetto?

Ad esempio , facciamo finta che una società crei WebsiteA (. com), e d'ora in avanti si chiami " WebsiteA ". WebsiteA crea un componente di autenticazione riutilizzabile per il loro progetto. Lo spazio dei nomi come tale:

WebsiteA.Auth.x.y.z

Un anno dopo, WebsiteA crea un nuovo sito web, WebsiteB e decide di utilizzare il componente WebsiteA.Auth creato in precedenza.

Questo oscura lo spazio dei nomi? La società deve aver utilizzato un alias separato dal nome del proprio sito Web come nome azienda nel suo namespace? Dopotutto, WebsiteA.Auth non è accoppiato direttamente a WebsiteA .com, e WebsiteA ora è più un progetto della società, piuttosto che l'intera azienda.

web-applications namespace

posta Craige 20.04.2011 - 17:22

fonte

3 risposte

Leggi altre domande sui tag web-applications namespace

Convenzione di denominazione per entità associative Come mantenere il changeset VCS / semplicità di revisione di fronte a commit parziali accidentali?

score 3 · Answer 1

Qual è la differenza che fai qui tra applicazioni web e "altre" applicazioni? Gli spazi dei nomi non dipendono e non devono dipendere dal tipo di progetto , soprattutto dal momento che la stessa libreria può essere utilizzata da applicazioni web e non web.

Se lo spazio dei nomi contiene il nome del sito web, in realtà, non è il nome del sito web, ma principalmente il nome del progetto, o in molti casi il nome in codice del progetto .

Il nome finale del prodotto è spesso diverso dal nome originale del progetto. In questo caso, non è insolito mantenere i vecchi spazi dei nomi contenenti i nomi in codice, qualunque sia il nome finale (in altri casi, il refactoring può essere fatto, ma può costare un sacco di soldi). Ovviamente, nel caso in cui permangano spazi dei nomi vecchi, è essenziale che gli sviluppatori conoscano non solo il nome del prodotto, ma anche il nome in codice del progetto per comprendere la relazione tra lo spazio dei nomi e i prodotti finali.

score 0 · Answer 2

La maggior parte degli spazi dei nomi con cui ho lavorato è stata più simile a questa:

CompanyName.TechnicalDomain.AppName.FunctionalArea.Class

o, nel caso suggerisci dove si intende condividere il codice:

CompanyName.TechnicalDomain.Common.FunctionalArea.Class
CompanyName.Common.FunctionalArea.Class

Nel caso di WebSiteB che ora utilizza il codice di WebSiteA, è un chiaro caso in cui il codice è candidato a diventare codice comune. Potrebbe valere la pena decidere a quel punto di spostare il codice nel comando .Common appropriato. namespace e quindi utilizzare .Common in WebsiteB. Alla fine dovresti trasferire WebsiteA su .Common. anche in futuri aggiornamenti.

score 0 · Answer 3

Prima di tutto, lo spazio dei nomi non sarebbe stato WebisteA.Auth.x.y.z (come WebsiteA è un sito web, come hai detto tu).

Facebook, MySpace, Twitter, ecc. è un'azienda e il loro prodotto è chiamato con il nome della società. Facebook, per fare un esempio, ha creato Cassandra, quindi avresti visto il progetto avere com.Facebook.x.y.z namespace (non sto confrontando la Cassandra di Facebook con l'Apache Cassandra, a cui Facebook ha dato il progetto).

Ho visto solo le librerie nei seguenti termini:

domainExtension.CompanyName.ProductName.x.y.z . Spero che questo risponda alla tua preoccupazione.